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PREFACE 


This  guide  is  one  of  a  series  of  Software  Acquisition  Management  (SAM) 
guidebooks  idiich  have  been  developed  under  sponsorship  of  the  Electronic  Systems 
Division  (ESD)  of  the  Air  Force  Systems  Command.  The  intent  of  the  series  as  a 
whole  is  to  provide  guidance  information,  supplementing  and  explaining  formal 
requirements  set  forth  in  official  documents  associated  with  the  800-series  Air 
Force  regulations,  to  assist  program  office  personnel  in  managing  software 
aspects  of  militar>'  system  acquisitions. 


.Air  Force  management  of  the  SAM  guidebook  series  is  provided  by  ESD's 
Directorate  of  Computer  Systems  Engineering  (ESD/TOI) .  This  guidebook  has  been 
prepared  under  ESD  Contract  No.  F19628-79-C-0186  with  the  System  Development 
Corporation  (SDC) ,  Santa  Monica,  California,  through  subcontract  with  the  Plan¬ 
ning  Analysis  Research  Institute  (P.ARI),  which  is  also  located  in  Santa  Ntonica. 
The  principal  investigator  for  this  task  is  the  guidebook  author,  Dr.  Lloyd  V. 
Searle,  of  PARI.  The  contract  manager  representing  SDC  is  Marcia  C.  Finfer. 
Administrative  guidance,  review,  and  coordination  were  accomplished  by  the 
project  manager  for  ESD/TOI,  Mr.  John  Mott-Smith. 


The  author  is  indebted  to  the  following  people  for  contributing  suggestions 
and  materials  which  proved  to  be  particularly  useful  during  the  development  of 
this  guidebook; 


•  Mr.  Ernest  Wade,  of  the  .Aerospace  Corporation,  for  use  of  materials  wliich 
he  had  developed  previously  for  guidance  in  preparing  specifications  for 
space  systems. 


•  Nhr.  Charles  I.  Silverstein,  of  SDC  (Denver,  Colorado),  for  comments  and 
suggestions  pertaining  to  problem  areas  associated  with  the  management  of 
commercial  items  in  system  programs. 


•  Ntr.  Robert  D.  Marshall,  of  SDC  (Sunnyvale,  California),  for  providing  samples 
of  functional  flow  block  diagrams  applicable  to  electronic  s>'stem  information 
processing  functions. 


nte  SAM  guidebook  series  consists  of  individual  documents  which  have  been 
issued,  as  they  were  completed,  in  the  form  of  ESD  technical  reports.  Following 
is  a  complete  list  of  guidebooks  issued  previouslv  in  the  series,  together  with 
their  National  Technical  Information  Service  fNTIS)  or  Defense  Documentation 
Center  (DDC)  accession  numbers: 
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SECTION  1.  INTRODUCTION 


A  general  aim  of  the  Software  Acquisition  ^lanagement  fSA'T)  guidebook  series 
is  to  help  promote  more  effective  acquisition  of  software  elements  in  military 
systems.  >tost  of  the  guidebooks  published  to  date  in  the  series  have  been 
devoted  to  selected  aspects  of  software  development  and  sunnort,  as  such,  in 
relation  to  management  concepts  which  apply  in  the  context  of  system  acquisition 
programs.  Tnat  general  focus  is  significant,  since  a  working  knowledge  of  those 
special  concepts  and  nrocedures  is  critical  to  the  successful  acauisition  of 
software/computer  resources  in  that  context. 

This  guidebook  differs  from  others  of  the  series  in  that  its  tonic  relates 
somewhat  more  directly  to  the  system  as  a  whole  than  to  a  system's  software 
elements.  However,  inte^'ration  of  software  with  systems  is  a  two-way  process. 
UTiile  most  of  the  effort  may  be  pointed  properly  towards  adanting  "software 
management"  to  the  system  program  environment,  there  is  a  growing  recognition 
that  the  prominence  of  software- -particularly  in  ground  electronic  systems- - 
also  has  imnlications  for  management  at  the  system  level.  The  system  specifica¬ 
tion  (the  Type  A  specification  as  defined  in  MIL-S-83490)  was  chosen  as  the 
topic  of  this  guidebook  largely  because  it  is  the  designated  source  of  basic 
reauirements  for  the  system  software  functions  and  performance,  and  because 
many  of  the  problems  associated  x\'ith  software  acquisition  in  systems  have  been 
traceable  to  inadequacies  in  those  basic  requirements. 

The  material  contained  in  this  guidebook  is  addressed  primaril>-  to  members 
of  system  Program  Offices  (POs)  who  are  responsible  for  software  aspects  of 
system  programs,  and  in  part  to  personnel  of  supporting  contractors- -although 
the  guidebook  is  not  intended  and  should  not  be  used  as  a  contractual  doc’ument . 
If  improvements  are  to  occur,  those  are  the  people  who  must  have  a  common  under¬ 
standing  of  the  system  specification  development  and  functions.  At  the  same 
time,  it  is  recognized  that  a  PC's  approach  to  the  system  specification  is  con¬ 
strained  by  basic  program  management  policies  that  are  determined,  for  each 
program,  at  or  above  the  Program  Manager  level;  hence,  the  discussions  also 
touch  on  certain  areas  which  appear  to  merit  attention  by  those  hicher-level 
managers. 
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The  organisation  and  content  of  material  presented  in  following  sections 
and  appendices  of  tins  guidebook  are  summarized  below. 

Section  2,  Nfodel  Concepts,  is  devoted  to  a  description  of  the  system  speci¬ 
fication  development  process.  Emphasis  is  placed  on  describing  the  levels  and 
nature  of  system  engineering  studies  which  are  normally  needed- -i.e.  ,  not 
necessarily  t>'pical  in  practice--to  develop  comprehensive  requirements  informa¬ 
tion  in  areas  that  are  significant  to  system  data  processing  functions  and 
performance.  One  objective  of  this  section  is  to  outline  the  manner  in  which 
the  technical  process  can  be  planned  and  managed  systematically  within  the 
framework  of  program  management  policies  and  milestones  established  in  such 
current  documents  as  APR  800-2  and  APR  57-1.  Key  elements  of  coverage  include 
the  following: 

a.  Levels  of  system  engineering  studies  are  described  ranging  from  derivation 
of  operational  requirements  through  functional  analysis,  advanced  develop¬ 
ment,  and  trade  studies  leading  to  system/system  segment  design. 

b.  Levels  and  objectives  of  the  technical  steps  are  related  to:  phasing  of 
the  svstem  program,  from  issuance  of  a  Statement  of  Operational  Need  fSON') 
through  conceptual  and  validation  phases;  identified  roles  of  Government 
agencies  and  contractors;  and  key  areas  of  the  system  specification  content 
affecting  computer  resources. 

c.  Technically,  the  focus  of  discussion  is  on  system  engineering,  which  is 
characterized  by  concern  with  functional  analysis  and  design  at  the  svstem 
level.  However,  the  description  also  identifies  activities  at  various 
stages  of  the  overall  process  which  require  significant  support  by  special¬ 
ists  in  software  engineering. 

Section  5,  Issues  and  Problem  Areas,  identifies  selected  areas  in  which 
problems  have  been  encountered  pertaining  to  development  and  uses  of  the 
s)-stem  specification  in  electronic  s'^stem  programs.  This  section  includes 
discussions  of  the  following  topics; 


a.  Intended  functions  of  the  system  specification  in  a  model  svstem  program., 
in  relation  to  functions  of  other  specification  t'-pes.  In  established 
policy  and  practice,  the  system  specification  has  some,  but  limited,  uses 
as  a  contractual  compliance  document.  Basically,  equipment  and  computer 
program  elements  of  a  system  are  acquired  most  directlv  acainst  lower-level 
(configuration  item)  specifications. 

b.  Current  problems  associated  wdth  PO  manpower  and  increasing  prominence  of 
commercial  components.  This  discussion  outlines  some  novel  uses  of  the 
system  specification  which  have  been  employed  or  suggested  to  allevuate 
difficulties  being  experienced  in  recent  system  programs. 

c.  Factors  of  risk.  In  general,  "program  risks"  involve  deficiencies  of 
either  a  technical  or  management  nature,  or  both.  This  discussion  suggests 
that:  few  if  any  system  program  failures  have  been  knoisn  to  result  from 
software  technical  limitations  as  such;  the  serious  troubles  encounte-.-ed  in 
actual  practice  have  typically  been  matters  of  (1)  inadequate  definitions 
of  requirements,  via  system  engineering  effort,  and  (2)  inadequate  program 
planning  and  management.  These  factors  point  to  a  general  need  for  wider 
use  of  the  validation  phase  as  a  device  for  reducing  those  prominent  risks. 

■^ppendix  A,  System  Specification  Preparation,  is  provided  herein  as  a  pre- 
liminaip’  basis  for  further  development  of  guidance  pertaining  to  preparation  of 
the  system  specification  in  accordance  with  format  and  content  instructions  con¬ 
tained  in  Appendix  I  of  MTL-STD-490.  A  conplete  guide  to  interpret  those 
instructions  comprehensively  for  electronic  systems  is  needed  but  is  not  yet 
available.  Although  clearly  in  line  with  this  guidebook's  title  and  objectives, 
the  adequate  develoument  of  such  guidance  will  require  a  longer-term  effort. 

•As  a  sample  approach,  however.  Appendix  A  presents  portions  of  a  guide  which 
was  prepared  at  The  Aerospace  Corporation  for  space  systems,  together  with 
supplementary  comments  on  a  few  of  the  paragraphs  considered  to  be  of  particular 
importance  to  software /computer  resources.  Portions  covered  in  the  sample  are 
confined  to  Section  .i.  Requirements,  of  the  system  specification. 


Appendix  B,  Sample  Paragraph  3.5.8,  contains  a  sample  of  system  specifica¬ 
tion  content  dealing  with  design  and  construction  standards  for  computer 
programs  which  has  been  developed  at  ESD  and  proposed  for  general  use.  The 
appendix  includes  comments  by  this  guidebook  author  on  suitability  of  the 
proposed  sample  in  relation  to  proper  content  and  functions  of  the  system  speci- 
tication.  Overall,  this  paragraph  deserves  more  careful  and  sparing  treatment 
than  it  has  general !>•  received. 

Appendix  C,  Sample  Functional  Flow  Block  Diagrams,  presents  examples  of 
functional  flow  diagrams  prepared  for  system  data  nrocessing  functions,  based 
on  format/content  instructions  contained  in  DI-S-3604.  These  samples  illus¬ 
trate  one  prominent  form  of  system  engineering  documentation  discussed  in  the 
preceding  Section  2  fModel  Concepts) ,  which  should  normall}’  be  included  as  a 
part  of  the  information  furnished  in  paragraph  3.1.4  of  the  system  specifica¬ 
tion. 

Appendi.\  P  and  Appendix  E  contain  lists  of  the  source  references  and  abbre¬ 
viations,  respectively,  that  are  cited  and  used  in  the  guidebook  text. 


NOTE  TO  READERS 


iiue  to  Widespread  conflicts  in  accepted  definitions,  use  of  the  term  "soft¬ 
ware''  has  been  systematically  avoided  in  most  official  Air  Force  documents 
dealing  with  acquisition  management,  for  many  years  (viz.,  AFR  800-14,  AFR  65-3, 
''!!!. -STr>-483.  Mil -STD-1521A) .  "Computer  program"  does  hav'e  a  recognized  .Air 
I-orco  definition  (e.g.,  in  MIL-STn-483)  which  is  relatively  precise  and  much 
less  subject  to  diverse  interpretations.  "Software"  is  used  in  this  guidebook 
because  it  is  established  as  a  part  of  the  SAM  guidebook  series  title.  However, 
readers  are  requested  to  note  that  its  intended  meaning,  throughout  the  text 
herein,  is  e.xactlv  equivalent  to  "computer  program(s)". 
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SECIION  2 


‘10DEL  CONCErrS 


>  » 


Air  Force  policies  and  guidance  for  acquisition  manapment  have  lone  been 
based  on  the  use  of  a  ''model’'  svstem  program  as  the  essential  reference  f’ame- 
Kork  for  managing  the  development  of  new  svstems.  The  model  for  a  s\'ster  procra' 
consists  basical Iv  of  a  nredetemined  scenario  of  management  actions  and  event.' 
kei'ed  to  a  standard  seouence  of  system  life-cvcle  nhases.  It  reflect.'^  estab¬ 
lished  relationshios  and  responsibilities  of  imnlementing/narticinatinf'  oreani 
cations  and  incorporates  a  snectrum  of  associated  standards  and  guidance  ner- 
taining  to  objectives,  procedures,  and  criteria  affectinv  tiie  prescribed  action' 
and  events. 

.Actions  and  events  identified  in  the  model  include  ones  for  which  some 
requirements  are  mandatorv  and  others  optional,  in  varv’ing  degrees,  h'hile  the 
construction  and  use  of  such  a  model  assumes  that  all  system  nrograms  will  liave 
a  broad  range  of  common  characteristics,  it  is  also  recognized  that  even  indi¬ 
vidual  program  is  likelv  to  depart  from  the  model  in  some  of  its  aspect.'.  Hov - 
ever,  the  important  underlying  principle  is  that  of  "management  bv  exception"-- 
i.o,,  bv  having  predetermined  solutions  for  the  planning  and  conduct  of  major 
parts  of  all  programs,  each  Program  Manager  should  have  relatively  more  time  and 
freedom  for  attention  to  the  special  aspects  of  his  individual  program. 

Thus,  the  assumption  that  standards  must  be  "tailored"  to  the  needs  of  each; 
program  is  inherent  in  the  model  approach,  although  the  widespread  recent  empha¬ 
sis  which  has  been  placed  on  the  tailoring  activity  as  .such  has  caused  manN- 
Program  Managers  to  lose  sight  of  the  fact  that  the  converse  is  also  true- -in 
that,  the  model  must  first  be  known  and  observed  before  it  can  be  sensibly 
tailored.  Considering  the  complex  spectrum  of  tasks  involved  in  manacing  the 
acquisition  of  an}'  large  militan-  system,  promi.'ing  alternatives  to  the  dc\'elop- 
nent ,  continuing  refinement,  and  use  of  the  model  approach  do  not  exist. 

Tins  section  outlines  a  model  approach  to  developing  the  system  specifica¬ 
tion  for  a  large  electronic  svstem.  The  approach  is  described  with  emphasis  on 
what  should  occur,  in  the  light  of  demonstrated  technical  and  management  needs 
of  ttic  process,  rather  than  what  iias  been  necessaril;'  tNT>ical  in  .actual 


practice.  In  accordance  with  purposes  of  this  guidebook,  attention  is  focused 
on  early  phases  of  the  life  cycle,  and  on  the  scope  and  nature  of  technical 
requirements  information  to  be  collected,  analyzed,  and  organized  as  a  sound 
basis  for  initiating  the  full-scale  development  of  a  complex,  computer-based 
system. 


2 . 1  Phasing  Considerations  -  General 

The  model  adopted  for  overall  phasing  of  the  system  specification  develop¬ 
ment  is  illustrated  in  Figure  2-1.  This  model  is  chosen  primarilv  because  it  is 
one  which  can  provide  for  meeting  needs  of  the  technical  process,  and  because  it 
also  permits  meeting  the  requirements  of  many  established  standards  which  apply 
during  conceptual  and  validation  pliases  of  system  programs.  At  the  same  time, 
t  incoqiorates  certain  assumptions  about  electronic  s>'stem  programs  which  are 
not  exiDlicitly  confirmed  or  emphasized  in  current  top-level  policies  for  major 
defen.se  systems,  nor  clearly  exemplified  in  most  of  the  actual  practice.  Prin¬ 
ciple  points  of  the  diagram  to  be  expanded  upon  in  following  sections,  including 
some  potential  points  of  issue,  are  summarized  as  follows: 

a.  Development  of  a  large,  digital  computer-based  system  requires  full  utili- 
zatior.  of  available  syster^  engineering  resources,  ever  the  maximum  available 
time  soar..  Significant  initial  steps  in  the  total  process  must  be  accom¬ 
plished  during  the  preconceptual  period,  in  conjunction  with  and  following 
initial  identification  of  the  operational  need. 

h.  Alternative  solutions  to  meeting  mission  needs  of  the  operational  command 
are  evaluated  jireceding  and  during  the  conceptual  phase  the  implementing 
command),  resulting  normally  in  selection  of  a  system  design  at  the  level  of 
SN'stem  segments/functional  areas.  The  initial  system  specification  includes 
firm,  system,  functional ,  perfermarrae ,  and  interface  requirements,  anui  allocc- 
ti.^nr  c'f  those  to  the  system,  segmcrztr.  Othen\lse,  it  should  provide  maximum 
latitude  for  alternative  design  solutions,  below  tlie  segment  level. 

\t  that  point  in  time--i.e.,  at  the  outset  of  a  validation  pliase--tlir  system 
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specification  should  exclude  performance  and/or  desian  requirements  that 
depend  on  questionable  technology,  either  hardware  or  scftrwarc. 

d.  A  validation  phase  has  not  often  been  conducted  for  electronic  systems, 
possibly  because  the  basic  hardware  is  not  t>'picallv  subject  to  risks  that 
can  be  effectively  reduced  through  such  activities  as  hardware  proofing  and 
nrototvpe  demonstration.  However,  the  typical  problems  that  do  occur  indi¬ 
cate  that  a  validation  phase  should  normally  he  mandatory,  for  the  primaty 
objectives  of  (Ij  accomplishinr,  sound  management  planning  and  f2j  completing 
the  definitions  of  requirements  for  the  system  and  its  configuration  items 
at  levels  that  are  adequate  for  undertaking  the  svstem  full-scale  develonment. 

Later  subsections  of  this  section  are  organized  to  correspond  individuallv 
with  the  three  periods  of  time  indicated  above  in  Figure  2-1.  Tne  period 
labeled  "Preconceptual"  in  the  diagram  represents  the  period  of  program  initi¬ 
ation,  for  which  requirements  governing  formal  documents  to  be  prepared  by  the 
commands  and  processed  through  Headquarters  U.S.  Air  Force  (HQ  USAF)  are  pre¬ 
scribed  in  ,AFR  57-1  (12  June  1979).  Significant  aspects  of  those  fomal  require¬ 
ments  to  be  considered  in  relation  to  the  technical  program  are  summarized 
briefly  as  follows; 

Tne  potential  beginning  of  a  system  acquisition  occurs  when  an  operational 
command  identifies  a  need  for  improved  capabilities  to  perform  its  operational 
mission,  in  the  course  of  on-going  analyses  of  its  ability  to  achieve  assigned 
mission  objectives.  Through  joint  analysis  and  coordination  with  other  commands, 
including  AFSC,  the  need  is  documented  in  the  form  of  a  Statement  of  Operational 
Need  SON!  and  submitted  to  HC  USAF  for  evaluation. 

The  .SON  evaluation  stage  may  include  the  preparation  of  a  Mission  Element 
Need  Statement  by  HO  USAF  for  submittal  to  the  Secretar>’  of  the  Air 

Force  if  indicated  b\  size,  scope,  or  other  criteria  which  would  indicate  a 
maior  defense  svsten,  or  Air  Force  Designated  Acquisition  Program,  (AFD.AP). 
ialiuation  of  the  SO.N  or  approv'al  of  the  NEN'S  constitutes  the  milestone  zero 
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decision,  authoricino  commitment  of  resources.  These  actions  are  documented 
in  the  Propram  Manapement  Directive  TPMD  issued  hi'  Ifi  US’iF  to  authorise  formal 
initiation  of  the  conceptual  phase. 

UTien  the  SON  has  minor  impact  or  involves  minor  risk,  milestone  decision 
authority  mav  be  delegated  to  the  implementinp  command,  through  issuance  of  a 
PMD  in  which  HQ  US;\T  snecifies  limiting  thresholds,  constraints,  and  obiec- 
tives  for  the  program. 

As  submitted  by  the  operational  command,  the  SON  itself  must  be  confined 
to  documenting  the  need  or  deficiency  in  functional  terms,  without  specifying 
or  recommending  a  specific  solution.  However:  (a)  it  mav  include  an  attach¬ 
ment  which  identifies  alternative  candidate  solutions;  and  (bl  further  studies 
by  other  commands  fnotably,  AFSC)  are  to  be  accomplished  and  reported  during 
the  period  of  SON  evaluation. 

2.2  The  System  Engineering  Process 

Considered  very  generally,  system  engineering  is  the  multi -disciplinan 
activity  which  begins  with  functional  analysis  and  arrives  at  a  total  system 
design,  through  a  process  which  considers  and  evaluates  a  spectrum  of  military, 
economic,  and  technical  variables  that  are  relevant  to  candidate  approaches. 

The  process  has  been  described  more  specifically  as  consisting  of  the  following 
principal  steps: 

a.  The  first  step  is  to  identify  the  mission  element  need  to  be  met  by  the 
system,  e.g.,  as  stated  in  the  SON,  and  translate  that  need  and  its  sub¬ 
elements  into  major  functions  of  a  projected  svstem.  For  example,  if  the 
need  relates  to  continental  defense  against  a  cruise  missile  threat,  the 
analysis  might  result  in  identifying  such  major  functions  as  air  sun'eil- 
lance,  target  identification,  weapons  control,  and  battle  assessment . 
Insofar  as  possible,  emphasis  is  maintained  purely  on  functions  without 
regard  to  whether  they  will  be  performed  by  people,  hardware,  or  softw.arc. 
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b.  Each  function  is  analyzed  in  relation  to  the  projected  militar>"  environment 
to  identify  subfunctions  and  associated  performance  requirements.  Perfor¬ 
mance  requirements  are  matters  of  speeds,  capacities,  accuracies,  and 
similar  criteria  which  bear  on  the  manner  in  which  each  function  must  be 
accomplished.  This  step  mav  involve  analysis  and  evaluation  of  alternative 
solutions,  at  the  functional  level.  It  also  includes  the  identification 

of  functional  interactions  (interfaces)  with  other,  existing  systems. 

c.  .Alternative  approaches  to  design  of  the  system--i.e. ,  in  terms  of  its  physi¬ 
cal  configuration --are  identified,  initially  in  terms  of  major  subsystems 

or  system  segments*,  and  trade  studies  are  performed  as  needed  to  select  a 
preferred  design  solution  at  that  level. 

Those  steps  are  not  intended  to  be  performed  discretely  in  the  sequence 
outlined.  Each  step  t>’pically  imposes  needs  to  iterate  earlier  steps;  and  the 
design  solution  tends  to  result  from  a  p’-ocess  of  successive  approximations. 

One  inherent  objective  is  to  arrive  at  an  end  design  which  fully  reflects  and 
is  traceable  to  the  basic  functional  and  performance  requirements  derived  from 
identified  needs  of  the  militarv’  mission. 

Figure  2-2  summarizes  the  basic  process  de.scribed  above,  and  also  suggests 
that  elements  of  this  general  functional  analysis/design  approach  continue  to 
aoplv  at  each  succcssively-lower  level  of  design  as  it  occurs  during  a  system 
program.  Although  labeled  as  the  "system"  engineering  process,  it  clearly 
shifts  at  later  stages  to  the  levels  of  engineering  design  for  vdiich  respon¬ 
sibilities  are  assigned  to  technical  specialists  in  the  system  hardware  and 
software  components. 

fhe  fact  that  the  term  "design"  applies  at  many  level':  has  significant 


*loT  Air  fore-  sy^tcmb  ,  this  step  must  include  the  applicaticn  of  acquisition 
management  a.s  well  as  technical  criteria.  In  this  context,  the  terms  "sub- 
.sN-stem",  "sistem  .segment",  and  "functional  area"  are  generallv  equivalent, 
with  tiie  e.Nception  that  instructions  provided  in  .Appendix  III  of  MIl.-STD-ASo 
ma^•  applv  in  special  cases. 
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BASIC  SYSTEM  ENGINEERING  PROCESS  -  SYSTEM  LEVEL: 


•  IDEffriFY  SYS1B1  ^UNCTIONS 

i 

•  EXPAND  SYSTEM  FUNCTIONS  S 
DEFINE  PERF/reSIGN  Rom’S, 

•  PERFORM  TRADE  STUDIES  R 

ALi_OCATE  FUNCTIONS 
TO 

SYSTEM  SEGMENTS 


LEVELS  OF  ANALYSIS  &  DESIGN: 


-  SYSTEM 


- SEGMENT 


-  Cl/CPCI 


-  COMPONENT 


Fipure  2-2.  Generalized  Elements  of  the  System  Engineer inr  Process 
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majia^emcnt  implications,  as  well  as  tecimical,  throughout  the  course  of  a 
svstem  acquisition.  Generally,  acquisition  responsibilities  are  assigned  to 
Doll  components,  commands,  agencies,  contractors,  and  their  organizational 
units  at  identified  lev'els  of  system  or  configuration  item  design.  Management 
techniques  are  associated  with  organizational  responsiblities  at  all  levels, 
which  depend  upon  the  technical  design  solutions  and  at  the  same  time  impose 
constraints  on  the  design  process.  Those  tend  to  be  most  visible  in  the  form, 
of  policies  that  each  s^■stem  segment  and  configuration  item  must  be  defined  in 
such  a  way  that  responsibilities  for  its  development  can  be  assigned  to  a 
single  contractor/agency,  and  of  subsequent  requirements  to  maintain  traceable 
interrelations  of  technical  products  with  such  management  instruments  as  state- 
ment.‘-  of  work,  specification  trees,  organization  charts,  and  work  breakdown 
structures . 

The  relevant  point  for  purposes  of  this  discussion,  however,  is  that  the 
ver\-  first  design  decision  which  occurs  to  initiate  that  whole  general  pattern 
is  the  one  which  identifies  the  new  system  itself,  hhile  that  decision  is 
close! V  linked  with  the  analysis  of  mission  needs  for  which  an  operational 
command  is  primarilv  responsible,  it  is  neither  a  direct  result  nor  a  direct 
purpose  of  the  mission  analysis  as  such.  Rather,  it  should  normally  be  a 
result  of  associated  system  engineering  efforts,  preferably  carried  out  by 
activities  which  can  provide  continuity  with  later  efforts  by  the  imnlementing 
command  to  develop  the  system  specification.  The  de.scriptirn  of  early  activi¬ 
ties  provided  in  the  following  section  is  ba.sed  on  this  general  premise. 


r 
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Generation  of  the  Systen)  Concept 


This  description  outlines  the  nature  of  prel iminan'  technical  tasks  v.hich 
should  be  accomplished  prior  to  the  becinninp  of  formal  specification  prepa¬ 
ration.  The  specific  technical  steps,  and  the  total  tine  span  over  whicli 
preliminaip’  studies  should  occur,  are  subject  to  wide  variations  for  different 
systems.  Hence,  emphasis  in  this  description  is  placed  on  levels  of  design 
decisions  and  tipes  of  related  technical  information  v.hich  should  result  from 
these  earlv  studies,  rather  than  on  a  fixed  flow  of  events. 

for  an  electronic  finformation  processing)  svstem,  the  first  and  major 
objective  of  this  period  as  a  whole  is  to  arrive  at  a  firm  definition  of  the 
system  concept.  .Associated  objectives  are  to  acquire  and  document  information 
pertaining  to  svstem  requirements,  design  approaches,  and  constraints,  initi¬ 
ating  the  essential  base  of  background  technical  data  which  will  be  needed 
for  continued  use  and  expansion  at  later  stages. 

Z . 3 . 1  Initial  System  Concept 

Not  all  SONS  are  subject  to  solution  by  new  system  developments.  Mien 
thev  are,  however,  the  initial  concept  for  a  new  system  is  likely  to  be 
related  to  the  mission  analysis  activities  which  led  to  identifving  the 
operational  need  or  deficiency.  Such  factors  as  obsolescent  technology, 
opportunities  to  exploit  new  technolog>’,  and  known  changes  in  the  threat 
environment  have  often  pointed  already  to  the  general  nature  of  a  possible 
new  system  by  the  time  they  are  reflected  in  statements  of  need  for  improved 
operational  capabilities.  A  new  or  modified  computer-based  svstem  is  clearly 
suggested,  for  example,  by  the  identified  inability  of  a  command  to  handle 
information  processing  and  communications  functions  associated  with  a  new 
surveillance  technique,  weapon,  threat,  or  area  of  militarv  operations. 

hTiile  associated  information  about  the  system  functions  and  probable 
design  characteristics  may  be  fairly  extensive  at  the  outset  in  some  cases, 
the  initial  svstem  concept  is  rarelv  adequate  as  a  basis  for  starting  the 
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5^•ste)Il  proj^’ran;.  Howe\’er,  the  concept  of  a  systeiti,  as  such,  is  an  indispensable 
starting  point  and  jjuide  for  the  further  studies  outlined  belo^\.  In  the  course 
of  further  examination,  the  initial  concept  may  be  confirmed  ajid  refined, 
altered,  or  perhaps  abandoned  in  favor  of  alternative  solutions  to  the  opera¬ 
tional  need. 

1.3.2  Operational  Requirements  Analysis 

Expressed  in  summan-  terms,  purposes  of  operational  requirements  analvsis 
are  to  identify  elements  and  subelements  of  the  operational  command  mission 
which  the  projected  s^•stem  is  intended  to  support,  translate  those  into  system 
functions,  and  identify  performance  requirements  associated  \\'ith  the  functions. 
"Requirements"  refers  here  to  functional  and  performance  characteristics  of  the 
projected  s\'stem,  as  distinguished  from  "needs"  which  refer  more  directlv  to 
the  coinm<'md  mdssion.  Except  for  that  difference  in  orientation,  this  first- 
level  system  analysis  activity  is  neces.sarilv  carried  out  in  close  coordination 
with,  and  with  continuing  active  participation  bv,  the  operational  command. 

(Ince  designed,  it  may  be  assumed  that  the  electronic  system  will  consist 
01  such  elements  as  digital  computing  and  communications  equipment,  computer 
programs,  personnel,  facilities,  and  possibly  .sensors  or  vehicles.  In  the 
operational  analvsis  acrii'ity  as  such,  however,  the  focus  is  on  the  scope  and 
nature  of  mission  elements,  relevant  factors  of  the  operational  environment, 
and  derived  requirements  for  data  outputs,  inputs,  and  nrocessing.  It  is  not 
normal !>•  practical  to  exclude  design  considerations  altogether,  particular!)’ 
in  view  ol  the  fact  that  this  level  of  analysis  must  be  iterated  and  refined 
at  later  stages  ot  the  system  program.  However,  the\'  should  not  be  permitted 
t e  uiiert  attention  from  the  mainline  pumose  of  identifying  and  defininc 
functional  recji;;  rements  in  tlie  operational  context,  since  those  will  become 
the  working  criteria  against  which  design  alteniatives  are  selected  and 
e'-aluated. 

Methods  and  area.s  of  emphasis  for  earl'’  stages  of  the  anali’sis  necessarili' 
\ap’  as  a  function  of  the  nature  and  complexit\'  of  the  mission  elements 
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involved,  levels  of  information  already  acouired  dv  the  operational  command 
organization,  and  similar  factors  affecting  the  degree  to  v.iiicli  initial 
system  concept  is  related  to  firmdy  prescribed  mission  tasks.  Successix'o 
iterations  in  some  aspects  of  the  activities  outlined  belou  will  be  required 
as  the  program  moves  into  later  stages  to  arrive  at  the  comprehensive  defini¬ 
tions  of  operational  requirements  which  will  be  needed  before  the  system 
specification  can  eventuallv  be  completed. 

a.  The  initial  task  is  to  translate  mission  elements  into  identified  fimctions 
of  the  projected  system.  Generally,  this  translation  consists  of  identi¬ 
fying  operational  processes  necessar>'  to  accomplish  the  assigned  military 
responsibilities  and  objectives;  and  it  often  involves  significant  atten¬ 
tion  to  delineating  the  system  mission  scope,  as  well  as  its  nature.  In 
some  cases,  answers  to  Questions  in  this  area  may  be  clearlv  indicated  in 
the  SOX'.  In  others,  substantial  effort  ma\'  be  needed  to  ex’plore  relations 
of  the  identified  need  or  deficiency  to  a  viable  svstem  concept.  Occa¬ 
sionally,  circumstances  may  point  to  the  advisability  of  identif^•ing  a 
limited  set  of  functions  to  be  further  defined  for  the  given  system 
program,  resen'ing  others  for  longer-range  planning.  However,  to  provide 

a  sound  basis  for  the  system  program  at  hand,  an  essential  objective  of 
this  activity  is  to  arrive  at  a  definition  of  the  system's  major  functions 
in  terms  of  both  their  focus  and  clearly-delineated  boimdaries. 

b.  The  functions  of  an  electronic  system  are  characteristicallv  functions  of 
data  processing.  Effectiveness  of  the  system  as  a  device  to  support  a 
militaip-  mission  will  eventually  be  assessed  in  terms  of  its  abilitv  to 
provide  data  (or  information)  outputs  which  meet  criteria  in  such  a'^ea.^ 
as  accurac)’,  timeliness,  and  sufficiency.  Thus,  the  technical  conte'it 

of  the  analysis  should  consist  in  large  part  of  identifying  the  required 
data  outputs,  then  tracing  the  manner  in  which  those  outputs  can  be  gener¬ 
ated  through  processing  operations  performed  on  available  system  inputs. 

For  early  puiqioses -  - i . e .  ,  of  defining  the  .system  concept  at  levels  ade¬ 
quate  for  initiating  a  scheduled  .acquisition  program- -  informat  ion  .about 
t}7'es  of  inputs,  processing  operations,  outputs,  and  associated  pcrformaiu;c 
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requirements  should  be  acquired  and  documented  at  the  rclativelv  gross 
level  of  maior  system  functions.  These  maior  functions  are  often  identi¬ 
fied  to  correspond  ivith  areas  of  the  assigned  militar>'  mission  [e.g., 
Operational  Planning,  Weapons  Control,  Strike  Effect  Evaluation).  To 
support  continuation  of  the  system  Program,  however,  this  effort  must  also 
include  the  systematic  collection  and  documentation  of  information  in  the 
related  areas  outlined  below. 

The  documentation  of  detailed  operational  reouirements  at  lower  levels 
should  be  initiated  as  early  as  possible,  and  expanded  as  rapidly  as 
events  and  available  manpower  will  permit.  Eventuallv- -preferably  before 
the  end  of  the  validation  phase- -precise  and  detailed  definitions  will  be 
needed  for  even'  single  tv^pe  of  data  input,  processing  operation,  and  data 
output.  Inadequacies  in  this  area  are  a  chronic  problem,  due  to  the 
tNTiically  massive  quantities  of  that  information.  While  there  are  auto¬ 
mated  techniques  that  can  assist  in  some  of  its  aspects,  the  basic  task 
of  identifving  and  verifving  user  requirements  associated  with  each  and 
every  data  item  is  inescapably  manual.  As  a  rule,  the  collection  of 
properly-documented  data  item  requirements  for  a  large  fixed  data  base, 
and  for  external  message  interfaces  with  other  existing  systems,  should 
be  well  under  waN'  by  the  time  the  SON  is  validated. 

As  indicated  above,  the  operational  requirements  analysis  is  primarily 
concerned  witli  functions  and  performance.  However,  design  considerations 
cannot  be  excluded  altogether,  since  they  inevitably  influence  the  nature 
and  form  of  maior  functions  chosen  for  analysis,  even  at  the  system  level. 
Maior  design  constraints  are  often  imposed  explicitly  by  policy,  or 
im’ilicitb'  b\'  oln'ious  considerations  of  technology'  or  expense;  functions 
■as  such  will  he  defined  and  carefullv  analvzed  only  \\'hen  there  are  reason¬ 
able  eroiinds  to  believe  they  can  be  imiilemented.  Hence,  a  base  of  design 
documentation  should  be  initiated  at  the  outset  which  can  be  progressively 
expanded  and  refined  durinc  the  course  of  later  activities.  At  each 
stage.  It  should  identifv  known  design  constraints,  design  alternatives. 
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aniJ  identified  question?  of  feasibilitv  deser\'in,L'  further  stud\'.  .\t 
cnrl\'  stages,  particular  attention  is  needed  to  ident  i  fx'ir.^  ■];  de.'icti 
assumptions,  where  thc\’  may  affect  the  functional  anaU'sis.  and  i.i’i 
needs  for  siiecial  research  or  feasibiliti-  studies  which  reuuire  long- 
lead  times  to  vield  usable  results. 


-.3.3  Design  Studies 


Current  policies  for  manor  defense  system  acquisition  recognize  the  need 
for  design  studies  during  the  preconceptual  period  for  numoses  of  identifN-inc. 
and  assessing  alternative  solutions  to  design  of  the  svste.m  as  a  whole.  AFP 
.f-l  assigns  responsibilities,  jointly  to  .AFSC,  .AFLC,  AFCC,  and  ATC,  to  iden- 
tifv  constraints  that  limit  alternative  solutions  and  comiiare  candidate 
alternatives  with  respect  to  technical  and  other  factors  of  feasibilitv.  In 
conjunction  with  these  activities,  .AFSC  must  also  prepare  a  urogram  management 
plan  for  the  succeeding  phases. 

Major  alternatives  for  electronic  svstems  tend  to  be  matters  of  design  in 
such  areas  as  command  organizational  structure,  geograph>'  or  denlo'-ment,  com¬ 
munications,  and  data  processing  technologies,  hhere  significant  ouc'tions 
exist,  special  studies  ma>'  be  indicated  to  assess  alternatives  with  re.spect 
to  relative  effectiveness,  technical  feasibility,  costs,  development  times,  and 
support  factors.  The  particular  nature  and  emphasis  of  these  studies  should 
generall>-  be  dictated  b>-  design  requirements  derived  from  the  preceding  anal}-- 
sis  of  functions  for  the  given  .svstem.  .Just  how  far  the  .system  design  should 
have  progressed  by  the  end  of  this  period  is  a  question  to  be  resolved  in  the 
light  of  such  considerations  as  the  following; 

a.  The  system  configuration- -and  each  realistic  alternative,  if  anv  exist-- 
must  be  determined  at  a  level  which  is  adenuate  for  urogram  management 
planning  purposes,  hstimate.s  of  feasibiliti',  costs,  procurement  approach, 
and  schedules  should  be  based  on  Projected  system  support,  including 
training  and  training  equipment,  as  well  as  svstem  operational  Uinctions, 

!  .  in  accordance  with  general  Air  Force  polic'-,  unnecessar\’  limitations  to 
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subsequent  design  solutions  bv  competing  sources  must  be  avoided.  Th:s 
nolicv  is  most  clearly  pertinent  to  design  in  the  areas  of  svstem  hard¬ 
ware  and  software  components. 

However,  questions  of  system  configuration  which  require  long  lead-times 
for  their  solution,  or  which  must  be  resolved  primarily  through  inter -comm, and 
efforts  and  decisions,  should  be  firml\'  resolved  before  the  next  nhase  begins. 
Micf  iiuestions  tend  to  be  characteristic  of  electronic  systems.  .\s  one  examnle, 
extensive  studies  and  coordination  were  needed  over  a  lengthy  period  to  arrive 
at  a  x'lable  gross  configuration  for  an  air  defense  svstem  in  terms  of  numbers 
and  locations  of  direction  centers,  taking  into  account  interactive  relation¬ 
ships  with  surveillance  radar  locations,  command  centers,  air  bases,  communica¬ 
tions,  and  command  organisational  units.  Decisions  at  that  level,  which 
establish  a  known  framework  of  major  narameters  and  boundaries  for  the  svstem, 
are  general Iv  essential  as  a  basis  for  delimiting  the  potential  scope  and 
cmphasi.'-  of  si'stem  encineering/information  processing  analyses  at  later 
.'tages . 
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2 . 4  The  Initial  System  Specification 

The  Program  Manageinent  Directive  issued  !>>•  n;  Af  to  initiate  tht- 

conceptual  phase  includes  directions  for  funding,  schedules,  approval  actions, 
and  program  management  oMectives  which  are  tailored  to  each  program.  T)ic' 
description  provided  in  this  section  assumes  that  the  recognized  nrimar''  tech¬ 
nical  objective  of  this  nhase,  for  a  major  electronic  s\sten.,  is  tc'  develop  <'u. 
adequate  initial  system  specification. 

The  system  program  is  managed  during  this  phase  by  the  Program  Office  fPO' 
established  by  .AFSC  in  response  to  the  PI®.  The  PO  is  the  designated  cenfal 
office  having  .-u.r  Force  responsibility  for  planning  and  management  of  the 
program,  as  a  whole,  including  contracting,  logistic  sunnort ,  program,  control, 
and  related  support  management  areas  as  well  as  engincoing.  Participation 
by  other  commands  and  Government  agencies  is  provided  through  representation 
in  the  PO  organization.  The  actual  conduct  of  continued  studies  in  the  techni¬ 
cal  (engineering':  area  is  carried  out  with  additional  support  bv  personnel  of 
AFSC  laboratories ,  a  Federal  Contract  Research  Center,  or  svstem  engineering 
contractors. 

2.4.1  System  Engineering  Analysis 

.^laior  ti'pet-  of  activity  involved  in  the  process  of  developing  information 
tc  be  provided  in  for  with)  the  system  snecification  are  outlined  in  Figure 
2-5.  Although  the  activities  are  highly  interactive,  as  the  figure  suggests, 
the  effort  as  a  whole  should  be  planned  and  structured  to  emphasize  the 
immediate  goal  of  yielding  information  in  the  many  categories,  and  at  the 
levels,  which  the  initial  svstem  specification  requires.  Once  the  conceptual 
phase  formalb  begins,  the  end  products  of  these  efforts  must  generally  be 
accomplished  on  a  tine  schedule  which  is  relatively  short  and  fixed,  as 
compared  with  the  pr-ecedir  period,  'lowever,  demands  to  maintain  flexibilit\- 
are  inlierent  in  the  svstem  cncmeering  process,  lo  the  degree  feasible, 
efforts  should  be  planned  and  managed  to  provide  for  repetitions,  expansion, 
or  redirection  as  indicated  bv  .actual  progress  and  results. 


I 'Ml) 
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INTIiCRAIT,  f,  VliRIIT 
RQrnS:  I’RRI’ARi: 

SYSTRM  Sl’I-rU  ir-ATIMN 


Figure  2-4  identifies  a  seuuenec  of  luaior  tasks  and  logical  steps  irn’oi. vecl 
in  the  process  represented  in  the  preceding  figure.  Narratives  beloc  arc 
ke\-ed  to  iilock  numbers  shoun  for  the  steps.  Cm  the  whole,  thi';  dcscvj pt  ion 
is  limited  to  a  summarc'  of  the  "mainline"  process,  the  full  scope  of  activi¬ 
ties  in  a  gi\'en  actual  case  is  clearlx'  much  more  conple.x. 

TA.'^.V  1  -  .WvLYcig 

The  obiective  of  this  task  is  to  collect,  organize,  and  analvze  Inforna- 
tion  about  system  operational  functions  which  will  provide  I'ai  direct  innuts 
to  sx'stem  definition  and  perfomance  characteristics  portions  of  the  5>'stem 
specification  and  ("b'  the  functional  requirements  basis  for  further  studc-  of 
support  functions  and  requirements/constraints  for  sc'stem  desipi. 

Block  j.l  Collect  and  Organize  Technical  Data.  .An  essential  earl''  step  is  to 
establish  a  data  bank  of  existing  information  about  the  system.  This  actiidt'- 
should  begin  by  comjiiling,  reviewing,  and  assessing  the  source  documentation 
resulting  from  the  preconceptual  period  studies.  Centralized  files  should  be 
organized  to  provide  for  continuing  access  and  expansions  as  the  analvsis 
proceeds . 

Block  1.2  Develop  Functional  Flow  Diagrams.  This  activit''  is  based  on  opera¬ 
tional  requirements  and  gross  system  design  decisions  resulting  from  earlier 
.studies;  it  includes  additional  studies  to  expand  that  information  as  necessam 
to  ensure  its  completeness  and  accuracy  with  respect  to  militan-  objectives . 
constraints,  and  the  operational  environment.  The  activitv  consists  of  devel¬ 
oping  functional  flows  and  Sj’stematical  1>’  documenting  tho.sc  in  fomis  suitable 
for  use  in  subsequent  steps  of  the  anal''sis.*  Initiall'  ,  s'-stem  reoinrements 
are  translated  into  one  top-level  diagram  whicli  identifie'^  the  i',rn<;s  mission 
operations  together  with  test,  production,  deplo'Tnent,  and  sunj'ort  functions. 


*',\hile  functional  flow  diagram  formats  are  optional,  clear  and  consistent 
rules  for  a  selected  approach  should  be  established  at  the  outset  of  each 
project.  Fo-"  punioses  of  this  description,  thev  are  assiuned  to  be  developed 
in  accord.anco  witfi  rules  and  widely-established  uses  of  the  diagrams  .is 
■  1  ini  d.  i  r.  HI  - S-  . 
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I-ifMjre  2-4.  ITow  of  Major  Technical  Tasks  Conceptual  Pliase 


At  thi?  stape,  flow?  should  be  further  developed  for  the  rnissjori  ( operat )onal  ; 
functions  at  the  first  and  second  levels,  at  a  ir.inimuri,  and  at  loue;  for' 

selected  subfunctions  as  needed. 

Block  l.t  Initiate  Requireinents  Allocations.  The  sx’^temat ic  allocation  of 
reouiremonts  tc  system  segments  is  initiated  at  tliis  stage  to  provide  a  ba^-'r^ 
fo?'  subsequent  -studies  of  design  alternatives  at  lower  lei’els.  S\'ste!;.  soi'mcr.t'- 
( subsN'stems .  or  runctional  areas)  are  likely  to  have  been  identified  in  a  prc‘- 
lim.inar;!  way  at  earlier  points  in  time;  but  their  verification  and  precise 
uelineation  is  a  progressive  process  which  will  not  be  fullv  completed  until 
tlie  end  c  f  the  i-alidation  phase. 

This  step  should  include  reviewing  and  assessing  one  or  more  proposed 
breakdowns  of  the  system  into  segments  for  soundness  in  the  light  of  available 
criteria.  Each  segment  is  a  major  part  of  the  systet'  which  fal  is  character- 
iced  as  a  technicallv-consistent  grouping  of  system  elements  designed  to  per-'oni 
assigned  portions  of  the  system  functions,  and  fb;  renresents  an  area  of  devel¬ 
opmental  responsibility  which  must  be  assigned  to  a  single  contractor  or  rKovem- 
ment  agency.*  This  allocation  activity  itself  serves  to  verify  or  alter  the 
preliminary  identification  of  system  segments,  in  that  a  sound  breakout  should 
permit  all  requirements  to  be  precisely  allocated  without  creating  cormdev 
interfaces  among  the  segments. 

The  allocation  process  begins  with  system  functions  identified  in  the 
preceding  step.  It  consists  of  assigning  the  functions,  subfunctions,  and 
performance  requirements  to  the  segments  in  such  a  way  as  to  identify  technical 
design  criteria  which  will  apply  tc  specifying  combinations  of  equipment,  per¬ 
sonnel,  and  facilities  needed  to  perform  each  function.  Systematic  documenta¬ 
tion  i.s  a  fundamental  necessity,  due  to  the  sheer  volumes  of  information 
involved  as  the  process  continues  during  this  and  subsequent  tasks.  'Mies  of 
si'stem  engineering  documents  which  should  be  generated  h\'  t)ii.<  actii'it\’- -and 
controlled  during  later  expansions- -are  exemplified  b>’  the  Requirements  Allo¬ 
cations  Sheets  and  Schematic  Block  Diagrams  described  in  Dl -S- .SbO.E  and  -Sb'P*. 


*This  is  not  to  sa\'  that  each  segment  must  be  assigned  to  a  separate  contrac- 
tor/agenc\'.  All  requirements  max-  be  assigned  to  a  single  contractor;  houex’cr, 
the  breakout  still  serves  sigmi f ic.ant  nurposes  of  managenient  visibilitx'  and 
control  fo’"  both  the  Air  Force  and  prime  contractor. 
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BlOvk  l.i  hvalunto  Recaiirements  for  Automa*: i on.  This  acti\':ty  consists  of 
analvting  performance/design  requirements  and  constraints  associated  with 
sx’sTer'  infoiTiation  processing  functions  for  man/machine  allocations.  Syster 
inputs  and  outputs  are  examined  with  respect  to  such  characteristics  as  sources, 
frequencies,  volumes,  formats,  contents,  securit\',  timing,  accurac)',  and  asso¬ 
ciated  implications  for  the  involvement  of  system  personnel  in  their  generation 
or  processing.  Decisions  are  based  on  evaluating  functions  and  requirements  in 
the  light  of  such  factors  as  technical  feasibility,  costs,  timing,  and  inherent 
needs  for  on-the-spot  Judgment  or  intervention.  This  analysis  should  proceed 
to  the  point  of  allocating  functions  among  the  following  three  categories: 

a.  .?lanual  -  essential  decision-making,  coordination,  analysis,  or  control 
functions  to  be  performed  by  conmand  or  staff  personnel  which  do  not 
implv  direct  interaction  with  system  input  or  display  equipment. 

h.  -iutomatec  -  functions  performed  by  equipment  without  manual  interv'ention. 

c.  M'ln-Machine  -  fiuictions  performed  primarily  by  personnel,  but  involving 
direct  interaction  with  automated  svstem  functions/subfunctions  through 
manual  input  and  display  devices. 

Tins  step  as  a  whole  should  be  accomplished  comprehensi vel>’  for  the  s>'ster. 
operational  (mission i  functions  and  for  major  support  functions  derived  from 
the  known  operational  requirements- -for  example,  functions  of  simulation,  data 
recording,  and  data  reduction  involved  in  system,  test  and  evaluation  or  train¬ 
ing.  \lthough  infonnation  about  support  functions  is  likely  to  be  variable, 
particular  effort  should  be  taken  to  ensure  that  general  requirements  are 
ident;fie^i  that  icill  affect  the  scope  of  needs  for  si’stem  personnel ,  liardware, 
;nk;  softw.art- . 

lilt  siniificant  initial  result  of  this  activit^•  is  to  arrive  at  a  first- 
levol  se]iaration  of  smteri  Sanctions  assigned  to  the  two  major  classes  of 
ohxient^  wiiich  ncrtnnr  data  processing  operations  in  an  electronic  si’stem-- 
namel'-,  personnel,  iii  the  one  h.and,  and  a  set  of  automatic  data  processing 
diarduarc/software  :  elcmc'nts  on  the  other.  In  the  case  of  personnel,  this  and 


later  steps  are  directed  towards  (a)  identifying;  the  tNpes ,  level-,  and  een- 
eral  characteristics  of  command  and  staff  positions  required  to  perform  the 
identified  manual  and  man -machine  tasks,  including  impact  on  training  needs  and 
the  operational  command  organization,  and  (b)  formulating  human  factors  engi¬ 
neering  requirements  to  be  imposed  on  the  system  data  processinr  hardware, 
software,  communications,  and  facilities. 

is  regards  automated  elements,  the  emphasis  at  this  stage  is  or.  collecting 
and  detailing  requirements  for  information  processing  functions  which  will  be 
further  allocated  eventually  as  between  digital  computing/communications 
hardware  and  computer  programs.  Immediate  objectives  are  to  identify  and 
catalog  those  automated  functions  and  derived  perfcnp.ajict  re(;uire:nents , 
encoTTTpassing  both  the  purelv  automated  functions  and  those  associated  with 
manual  inputs  and  displays. 

Block  1.5  Organize  Requirements  for  Software.  A  final  step  in  this  task  is 
to  integrate  and  organize  data  resulting  from  the  preceding  steps,  and  to 
translate  the  aggregation  of  those  requirements  into  criteria  for  svstem  com¬ 
puter  programs.  Tlie  process  of  integrating  operational  and  support  require¬ 
ments  must  include  their  ev'aluation  with  respect  to  such  characteristics  as: 
adequacy  in  meeting  mission  needs  of  the  operational  command;  environmental  and 
organizational  contingencies;  functional  interfaces  with  external  svstems/ 
organizations;  generation,  content,  and  uses  of  fixed  data  bases;  and  major 
factors  of  loads,  volumes  of  data,  re.sponse  times,  growth  potential,  and 
security. 

The  integrated  requirements  for  automated  functions  are  analyzed  initially 
to  arrive  at  an  overall  assessment  of  the  system  software  characteristics. 

During  later  steps,  hardware  and  software  trade-offs  will  be  examined;  and 
still  later  (during  the  validation  phase),  firmly- identified  characteristics 
of  the  computer  hardware  will  become  a  prerequisite  to  the  identification  of 
computer  program  configuration  items  (CPCIs)  and  the  initiation  of  their 
development  specifications.  At  earlier  phases  of  an  electronic  system  program, 
however,  software  is  the  "lead  item"  unon  who.se  characteristics  the  determination 
of  requirements  for  the  system  data  processing  hardwai'e  must  be  based. 

jq 


In  the  ?\’?teiii  snec i f ication ,  software  recjuirernents  will  continue  to  be 
exTiressevi  nredorriinanrl\’  in  terms  of  functions  and  Derformance--and,  in  terms 
of  fuTiCTions  and  performance  that  will  continue  to  be  shared  with  computer 
harciwarc.  The  specification  of  software  "design",  as  such,  at  the  svstem 
specificat ion  le'tel  is  limited  to  ia)  general  design  requirements/constraints 
design  standards  cited  in  paragraph  5.5.8)  and  rh)  the  structuring  of 
scdtwarc  elements  into  CPCis  fto  he  acco7Tr>l ished  during  the  validation  phase,. 

M,-v,.cvt f ,  turti'.er  examination  of  software  design  approaches  should  be 
r\  'i'.'  icd  as  an  impn'-tarit  •p.ir''  of  suhseouent  steps  at  this  staee,  in  order  to: 
\er':''-'  fcasit:' it -•  .ind  cornnjeteness  of  the  requirements;  identify  and  assess 
s‘C;i af -I  tie-;; :  t  iechnioue-'  as  tliey  c,.pi'-'  to  rclevartt  functions--e.c.  ,  data 
'■  :-■■■.  r  ,.na 'cr  nit .  :■  r.ie-sharin;; .  parallel  processing,  cornmuttications ,  data 
.  .'-s  crntrol;  and  fu'mish  essential  criteria  to  assist  jn  determining  require- 

•  o  :  or  the  desici  cf^’  tdata  nrocessin.':  hardware. 


,.'_5h  Di-^IGh  TR^IE  SllJinhS 

This  task  consists  of  a  series  of  systematic  atialyses  to  assess  the 
a,lv3Titaees  and  disadvantages  ftrade-offs )  of  system  data  processing  design 
a 'tenia  tine-.-  witii  restiect  to  both  hardware  and  software.  TTie  purpose  is  to 
.■.•onstruct  a  rational  set  of  design  concepts- - i  .e. ,  a  feasible  system  configura- 
nor,--;;-'  a  Korkinc  !.a‘-is  for  subsequent  inte.cration  of  system  requirements 
infoiTiat  ion  Jurir..',;  ‘lie  conduct  of  Task  3.  Bv  this  stage,  it  is  assumed  that 
inaior  parameters  of  the  system  configuration  hai'e  been  established  through 
p- i  •  .  icc'sions,  pt  mitt  in.e  taese  studies  to  focus  on  a  relatively  finite 
ran.-c  o;  desigr.  alternatives,.  Tn  each  case,  the  identification  of  significant 
.'f  1  teiTiat  i'.'e.-'  to  ex.amine  is  a  truatter  of  tec)inic.a]  iudgment  based  on  knowledge 
;  ;  The  sivan  system  requirements  and  constraints,  even  with  those  limitations, 
not  ncmiialle’  necessaro'  or  practical  to  analvcc  all  possible  alternatives 
(' ■  ;vel c.  Tiv  ohiective  is  to  interrelate  a  set  of  realistic  design 

s.-'lur  iv.as  with  se'-tem  requirements  in  sufficient  depth  to  assure  that  the 
recui  rcaent --  will  remain  valid  during,  the  course  of  later  do.sigm  trade  studies 
at  jor.er  hu-els. 
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Block  2,1  Tecmiiques  and  Criteria.  A  first  step  in  this  task  is  to  orot'ide 
Korking  tools  for  the  ajialysis  activities.  Techniques  anJ  criteria  to  b(- 
employed  in  conducting,  the  analvses  should  he  est.nhl ishcc.  at  the  outset  in 
such,  areas  as  the  following: 

a.  .Anali’sis  techniques  for  assessing  design  altematit'es .  inciutiine  format 
and  content  of  trade  studv  summaries. 

b.  Functional  and  design  requirements  for  specific  trade  studies. 

c.  Established  constraints- -e.g. ,  with  respect  to  facilities,  power,  envir¬ 
onment,  communications,  manpower. 

d.  Evaluation  criteria  with  respect  to  critical  desijTi  ohiectives  (loads, 
timing',  secondan-  characteristics  of  eouipment  (the  "  LI  hies"  i,  and 
computer  programming  feasibility  factors. 

Block  2.2  Identify  Candidate  Alternatives.  This  activity  involves  the  exer¬ 
cise  of  engineering/data  processing  judgment  based  on  knowledge  of  hardware 
and  software  design  approaches  that  are  pertinent  to  the  system.  It  is 
important  that  analysts  be  aware  of  the  range  of  applicable  technolo,ci'  during 
the  time  frame  of  the  system  program,  able  to  identify  the  areas  in  which 
significant  questions  exist,  and  prepared  to  assess  candidate  solutions  obiec- 
tivelv.  The  activity  consists  of  constructing  an  approach  to  the  "svstem 
architecture"  and,  at  this  step,  identifying  alternatives- -involving  computer 
hardware,  consoles/terminals,  communications,  and/or  software- -which  merit 
further  systematic  comparison  with  respect  to  performance  and  factors  of 
feas ihil it>'.  As  the  tasli  progresses,  additional  or  related  altematii'es  mai' 
be  identified.  However,  the  analysis  as  a  whole  will  tend  to  be  fruitful  to 
the  degree  that  the  "right  questions"  are  formulated  at  the  outset. 

Flock  2.3  .Perform  Trade  Studies.  A  trade  stuch’  consists  of  comparing  two  or 
more  candidate  designs  with  respect  to  all  of  the  characteristics  which  are 


inportant  to  the  intended  application.  Characteristics  to  be  considered 
include  not  onlv  the  identified  performance  requirements  but  also  factors  of 
cost,  availability  and/or  development  times,  operability,  maintainability, 
grov.th  potential,  safetv,  impact  on  interfacing  or  support  elements  of  the 
system,  ,ind  flexibility  with  respect  to  lower-level  design  solutions.  Occa¬ 
sional  Iv,  certain  performance  aspects  may  be  subject  to  analysis  through 
simulanons  or  matiiematical  modeling.  Cienerally,  however,  the  analysis  con- 
-sist.s  oa.sicallv  of  examining  the  advantages  and  disadvantages  of  each  candidate, 
rating  the  candidates  with  respect  to  each  relevant  characteristic  [including 
exaiericnce 1 ,  and  arriving  at  an  overall  assessment  based  on  the  complete  set 
of  coiirparisons . 

Flock  2.4  JYepare  Trade  Study  Reports.  Each  study  performed  in  the  preceding 
sten  should  be  documented,  preferably  in  a  summaiy  form  similar  to  the  Design 
Iradf  -'.tuviv  Report  described  in  Dl-?-3606.  Bacicup  data  should  be  included 
wnerc  indicated  to  clarify  the  selection  of  alternatives,  evaluation  criteria, 
and  identified  questions  or  points  of  importance  to  be  further  investigated 
and  reported  b\’  competing  contractors  during  the  validation  phase. 

T'wSk  >•  -  TNTEGRATF  AND  DOOJMENT  SYSTBl  REQUIREMENTS 

Tlie  function  of  this  task  is  to  analyze  information  available  from  pre¬ 
ceding  studies  and  document  system  requirements  in  forms  which  will  be  directly 
useful  in  preparing  the  system  specification  and  associated  program  plans. 
Product. should  consist  of  (a)  an  organized  collection  of  system  technical  data 
and  ill  a  report  or  scries  of  reports  containing  summaries  of  the  studies 
accomplished,  inputs  to  program,  planning  documents,  and  comprehensive  recom¬ 
mendations  fm  content  of  the  initial  svstem  specification. 

I. lock  .  I  ^A-stem  Recjulrements  Descriptions.  This  step  consists  of  compiling 
organized  descriptions  of  information  and  requirements  to  be  covered  in  Section 
of  rhe  sy.^tem  specification.  It  involves  reviewing  inforitiation  derived  from 
pri  ced  inc  ta.sks.  asse.ssing  it  for  completeness,  and  augmenting  it  bv  further 
ana  i '.-Sis  as  nci  e.ssan'  to  provide  recommendations  covering  (a'  functional, 
pericrmaiic'.  .  interface,  and  design  requirements  for  the  s>’stem  as  a  whole 


tUid  'bl  allocations  of  the  requirements  to  firml>’- identified  si'stem  sefmicnts. 
Descriptions  in  the  significant  areas  listed  below  should  be  supported  by 
functional  flows,  schematic  block  diagrams,  and  other  svstcm  engineering 
documentation  relevant  to  each  area; 

a.  Svstem  definition.  Descriptive  material  defining  the  system  as  a  whole 
should  be  provided,  covering  mission  objectives  and  constraints,  integra¬ 
tion  with  other  systems/capabilities,  operational  and  maintenance  concents, 
characteristics  of  the  threat,  and  other  aspects  of  the  mission  affecting 
design  requirements  for  the  system. 

b.  Interfaces  with  other  systems,  for  an  electronic  s\'stem,  inter-s\'stem. 
interfaces  are  matters  of  communications,  relating  to  both  (1 i  character¬ 
istics  of  automatic  data  and/or  voice  communications  media  fhardware/soft - 
ware)  and  (2)  messages,  to  be  outnut  and  received  by  the  given  svster. 

All  of  those  must  he  identified  at  this  stage  and  also  defined,  at  least 
in  functional  term.s,  at  levels  sufficient  to  delimit  their  scope  and 
nature.  However,  a  considerable  portion  of  this  effort  is  likely  to  be 
spent  in  searching,  compiling,  and  organizing  data  (or  references  to 
available  sources)  in  the  form  of  detailed  definitions  which  alread^•  e.vist 
for  interfaces  with  external  systems  and  organizations- -often  at  the  level 
of  message  ti-pes,  formats/contents,  frequencies,  and  volumes,  together 
with  known  characteristics  of  the  communications  links.  Those  constitute 
nredeterndned  constraints  for  the  new  or  modified  system  which  should  be 
identified  coimirehensively  in  advance  and  made  visible  in  the  initial 
svstem  .specification.  , 

c.  Command  organization.  Tlie  command  organization  should  be  described  in 
terms  of  levels  of  command,  mission  responsihi lities  of  identified  orga¬ 
nizational  elements,  and  functions  to  be  nerformed  by  those  elements  at 
specified  operating  locations.  It  should  include  a  preliminan'  estimate 
of  tg’pes  and  numbers  of  personnel  reejuired  for  system  operation  and  sui^- 
port,  taking  into  account  the  projected  locations,  nomal  and  emergenc'' 
operating  modes,  and  planned  dut\'  cycles. 
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S\'ster  perfoTTiiance.  Tliis  description  should  include  coverajie  o-*^:  iden¬ 
tified  "lodes  and  phases  of  svstem  operation;  performance  reouirements  for 
the  svstem  as  a  whole;  and  performance  requirements  for  identified  system 
functions  and  subfunctions.  Performance  requirements  for  the  system  as  a 
whole  normalb'  relate  to  total  system  capacities  and/or  response  times- - 
e.p.,  total  capacity  for  handling  target  tracks  or  simultaneous  intercepts; 
minimum  times  to  accom^ilish  threat  identification  and  waminp  or  other 
action.  Descriptions  of  information  processing  functions  should  emphasize 
coverage  of  operational  and  support  functions  at  the  hicher  levels--i.e. , 
those  identified  in  first-  and  second-level  functional  flow  diagram? - -but 
s'nould  also  e.vtend  to  lower  levels  to  the  degree  indicated  in  each  area 
bv  \-erified  operational  needs  or  desii-n  constraints.  Each  function/- ub- 
^'unction  IS  described  in  terms  of  identii^ied  function  inputs,  outputs,  and 
processing  operations,  together  with  associated  performance  requirements. 

At  this  stage,  a  large  bodv  of  detailed  data  should  exist  pertaining  to 
the  inputs  and  outputs,  in  particular,  organized  in  a  form  that  can  be 
referenced  here  and  made  available  for  later  uses.  If  the  system  involves 
a  large  data  base,  the  description  should  include  identification  of  the 
data  categories  and  twes,  estimated  sizes  of  files,  references  to  exist¬ 
ing  data  definitions,  and  requirements/responsibil ities  for  data  collection 
;ind  maintenance. 

Ai  locat  ion.^^  to  svstem  segments.  A  significant  Part  of  the  final  report 
should  he  devoted  to  the  grouping  of  perform;ince,  design,  and  interface 
requirements  into  s>’stem  segments.  The  segments  are  identified  b)'  titles 
and  defined,  basical  1>',  b^•  their  allocated  functions  and  requirements. 

Ml  functions  and  performance  requirements  (see  d  above)  should  be  accounted 
for,  incluuing  total  s^■stem  reciui rements  which  are  apportioned  between  two 
or  I'lore  segments.  At  the  performance  level,  allocations  stiould  be  supported 
hv  schematic  block  di.'njrams  ( first -level  I  in  which  functions  assigned  to  the 
se'mients  .are  traceable  To  the  svstem  fiuictional  flows  and  the  nature  of 
functional  interfaces  is  clearlx’  identified.  Interface  requirements  imposed 
on  eac'n  seimienr  inchkle  both  functional  interfaces  tliat  arc  identified  and 
.lefineil  with  other  segments  and  external  svstem  interfaces,  as  allocated. 


34 


The  erirr.a:-'-  fanclior.s  beinj.',  allocated  are  ones  Ktncl’,  v/ill  be  perfoniiet! 
tl'a'Que,!?-  the  combined  operation  of  command  ■nersonnel  and  com’^ntcr  nrocram' , 
oneratinc  in  the  context  of  general -nurnose  dicital  comnotin';  eciuinmcrit, 
di,s''la'’/mariual  innut  dei'ices,  and  communications  links.  \n:iJ\'se.‘^  v>er;nriit\! 
durinq  preceding  tasks  will  have  extended  the  <i-.stem  secnaent  anocation" 
tiie  point  of  idcnt i fvmp  further  reouirements  .and  constraints  .'"or  sec^'ient 
desi.cn  with  rcsnect  to  tiiose  elements.  The  descriotion  ’'ixn-ided  hei‘c 
should  include  a  full  account  of  those  extendeti  icsuits,  topetnei  v.’t!. 
recemmendat iojis  for  the  levels  of  design  reouirements  to  be  imnosed  on  each 
seement .  Pecommended  and  limiting  characteristics  should  be  identified  in 
such  areas  a.s  the  folloKint;; 

--General  logical  and  physical  eouipment  configuration  and  .ceopra’tiic 
locations . 

--Lstimated  numbers  and  nroces.sin.c  characteristics  of  commit ers- -speeds , 
capacitie.s,  u’ord  structure,  or  other  design  constraints. 

--estimated  n'ambers,  types,  and  capacities  of  peripheral  device.s  and 
requirements  for  special  scmthetic  signal/messa.ce  cencrating  or  inter- 
facL  eouipment. 

- -Nui’t'ers ,  capacities,  and  t\T)es  of  operator  consoles,  terminals,  or 
special  .-imulation  consoles,  together  Kith  innut/control  and  disnlai’ 
reouirements;  requirements  for  special  displai's  Ce.g.,  large  wall)  or 
iiardcop.'  pi'inters. 


-  -  Pecommended  structure  and  characteristics  of  inission/oncrational  and. 
.sunport  computer  nrocr.'im.'- -e . q.  ,  langua.ve  forms,  data  base  nana'’cr,cr.t , 
CPeratiiic  s\-ctem.  s’mulat  ion/d.ata  reduction,  maintenanccAliagnost  ics. 
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Block  ~.2  Inj^uts  to  Program  PL'ins.  Idirin.c  the  course  of  the  tiiree  syster, 
ongineerint;  tasks  outlined  above,  the  Program  Office  has  also  been  responsible 
for  p-reparinp,  coordinating,  and  integrating  appropriate  planning  documents 
to  suppor*  the  milestone  I  decision.  The  Program  Management  Plan  ffMP) 
includes  a  prominent  section  (Section  4,  System  Engineering  and  Confi.guration 
'■lanacement  '  wi.ich  should  be  based  on  information  derived  primarilv  from  the 
technical  effort,  ("'ther  sections  of  the  PMT*  and  other  plans  are  the  primaio- 
res’Y'iis i!  1 1  it;-  of  participating  commands  and  such  other  elements  of  the  PC 
as  procurement,  procram  control,  and  logistic  support.  However,  most  of  those 
other  plans  depend  heavilv  on  inputs  from  the  technical  program  to  be  accurate 
and  aciociuate.  Hence,  in  parallel  and  integrated  with  the  conceptual  phase 
-SN’ster;  engineering  anal\'sis,  significant  engineering  management  efforts  should 
nave  been  accomplished  to  support  the  development  of  planning  information  in 
such  areas  as ; 

--Program  Costs 
--''kistc!'  Program  Scliedule 
--Statement  of  Isork 

- -Prel  irninan'  Work  Breakdown  Structure 
- -iHi'terminat ion  and  Findings  fniiFl 
•-.Advanced  Procurement  Ilan 
--Source  Selection  Pi.-m 

-  -  Rea.;  Propertv  Fac  il  i  t  ies  Plan 

-  Test  .and  1  valuation  Master  Plan  fTL'-n’' 

--integrated  Logistics  Support  Plan 

- -i.iom]iuter  Resources  Integrated  Support  Plan  (CRISP) 

-  S'Sten;  (iperutional  Concent 

_  .  -i .  -  !  're;  Kirn:  ion  of  the  S]  lec  i  f  i  ca  t  i  on 

'-y^-terr  spec;  fic.ition  should  be  prcnaied  before  the  end  of  the  concen- 
tii.ii  'in.-n',  initial  1\'  in  draft  fom.  fni  re\’iew  and  coordination  hr  partici- 
p.itinc  coniman  '.-.  'ollnwine  coord inar  ion ,  it  i'^  submitted  to  higher 


headquarters  a?  a  nart  of  the  documentation  packace  requif  .'  evaluat  ions 
leading  tc  the  milestone  I  decision. 

The  preparation  process  involves  translatinv  the  technical  infomuit^  i ''r 
described  above  intC'  careful U'- formulated  stateaients  of  SN'steiv,  reauireme:;:^ 
i.'hich  complv  with  format /content  instruction.';  of  MI  I  -  ,  Appendix  i. 

observing  sup’plementarx’  instructions  {  rovided  in  Appendix  I:  I  of  Mil  ST'  is' 
rUSAF '  to  the  degree  that  tiiose  apul'-  to  the  i  ive;i  progran:  .at  tnis  st,),  -; 

a.  Tne  decision  may  he  made  to  urite  the  specification  in  the  for^  of  one- 
general  volicne  and  a  separate  volume  for  each  system  segment.  In  t!  i.s 
case,  the  format  should  follow  instructions  in  paragrapi'.  31.  t  cf  ^TI-.‘TT- 
dS3. 

b.  Content  in.structions  provided  in  dg'"'  and  i.S.t  inara.  ,30. 3i  arv 

for  the  fill ly-complete'!  specification.  At  tins  stage,  significant  .ieci- 
sions  to  be  made  relate  tc  the  appropriate  I'egrees  of  incoTidietem  ss  a* 
which  requirements  zhculd  be  specified  in  certain  areas.  In  general, 
complete  and  definitive  requirements  should  be  specified,  in  most  areas 
whicii  pertain  to  svstem  definition,  dc.sign  standards,  and  other  charac¬ 
teristics  of  tne  system  ar  a  whole  fi.e.,  covered  in  paragraphs  '^.i  t.hrough 

of  the  specification'.  !iowe\'er,  requirements  in  naragrapii  3,'  T-unc- 
tional  Area  Characteristics!  and  3.1. a  ''System  Diagrams',  in  particular, 
must  be  carefullv  formulated  to  HI  include  all  pcrfonnaiice/inl erfacv 
requirements  and  design  constraints  which  have  been  firmly  established 
and  verified  at  this  time,  but  (d-  permit  ma,ximum  latitude  for  further 
analvsis  ,'ind.  hardware/sc ftware  design  solutions  h\'  competing  so'irc'  ^ 
during  the  validation  phase. 


i'o-n:"lct  iiu;  the  Svsterr.  Specification  -  \'ai  idat  ion  Phase 


'laior  ;.;oals  of  the  validation  nhase  are  to  expand  and  refitic  the  system 
svecificat  ion,  establis'h  fim  performance  specifications  for  configuration  ite^.s 
which  meet  s^•ste^l  requirements,  and  promote  the  accomplishment  of  comprehensive 
contractor  planning  for  svster  development  which  is  realisticallv  consistent 
reduced  procrar  risks.* 

■■;ie  recluiicai  '  tudies  pf  orinciptii  interest  to  the  process  o:  expanding 
an.,  co’-'-detinc  the  sx’stcm  speci ficat ion  durine  a  validation  phase  are  those  con- 
•  u'.ctcd.  r  V  contractors,  iiowever.  tiie  respon'^iblc  Program  Office  must  Plan  and 
•’:anace  this  r>iiase  as  a  whole  to  encompass  a  total  of  three  succcssi've  time 
period'- ; 
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1 

PU^NNi^i' 

imE.MFMTATION 

EVAI.IIAT10N 

•  f'erf^'rri 

•  Cont i'sf tor  Produft* 

•  Tt  fp.p  r  I  RTf 

•  E>’pant<  Sp^r  1  f  Irpt  }<>r. 

•  Update  Svster  ^  ^  1 1  on 

«  'm'  1  •  'mUI  r  P  5 

•  ffpp«r**  It#*"*  f'er f <'rmAnf 

•  ffprtatf'  rrop.rp»ri 

•  /  V.  1  r  ’  fnn  r  T  t  ‘ 

_i 

•  f’rcpflr®  ^lnn<  f* 

_ 

•  r‘r<»r«»rr  for  TT 

'  l.iir.inc  ;s  aci ninpi  is'.ied;  during  ati  initial  period  following  the  milestone  1 
..C',  I '  .oi!.  Si iTii  f leant  i.  ffort  is  required  to  '■'repare  program  plannine  docu- 

m.crO',  the  Keouesr  for  Proposal  'RFPl  package,  select  sources,  and 

.award  contra.ct  s. 

'  .  l;m'ie"ientat  ion  .iccompl ished  Iv  the  selecte^i  contractor  1  s  ) . 

P.valuatipn  con-  is*';  of  assessing  tiic  results  of  contractor  efforts,  updatin'; 
■  i;:.  e.xn.indinv  nrocrai"  plains,  and  preuarim'  document  .'it  ion  required  for  the 
”  ;  1  ■  ■  -  T  (UK-  i  !  dec  1 U'li . 

'■'■.■••■Ill'll.'.’  .' 1 '■•,■""■  ions  of  niaior  and  siil;s  uiiar'*  'i!' ici't  I'ces  for  tf.t'  val  id.'it '.  or. 
■fi.ira.  .i;a  PT'O'.  idl'd  ill  ,\i  S(d'  MM'-o  (dnapter  i  and  M'SCP  SOo-(  iCdviotcr  c  . 

'V!  li'-''  t.d  Iterein  f'^r  .'i  lurtlier  discu-sion  of  risks  enc.iuntercd  in  olectrcnic 

'■'•-ter:  ni'O'Uar's. 
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Z.?.l  Hanning  riJid  I'reparntion 

Hiring  thi?  first  period,  the  initial  svster"  snecifHation  nrenared  during 
the  conreptual  nhase  is  rex’iewed  and  revised  as  neccs,sar>-  to  refJert  additioTiaJ 
information  o-  ihanres  resulting  from  the  milestone  I  evaluations  and  decision: 
The  svstem  specification  Kill  begin  during  tlie  next  period  to  nerfoni'  :ts 
nificant  role  as  t!ic  nriniarv  dorament  eoi'^eming  tecimical  ohiectives  for  th'. 
sys'em  program..  After  being  estaldished  at  tliis  time  h'  the  pt'';  con I'l L’cra:  lOi; 
control  hoard  fC.CB'  as  the  functional  baseline,  no  further  changes  mac  occur 
excent  through  formal  processing  and  approval  cf  engineering  change  pronosal- 
fF.CPs  ! .  E.xpansions  to  be  provided  later  by  the  validation  phase  contractors 
a^e  included  among  ’’changes"  which  recgiire  that  formal  proces.sing.  llowevoT  , 
effort  should  he  made  at  this  time  to  nnnir.ite  tne  iikcliiiood  that  those  will 
need  to  include  changes  to  the  basic  requi remen t .1 ;  it  is  to  be  honed  th.at  the'-' 
can  be  limited  tc  ex'pansions  involving  further  definition  of  system  dc=i;gn  wit!' 
respect  to  hardware/software  configurations  within  the  svstem  segments. 

Evaluation  of  the  system  specification  for  adequarv  .should  be  su’pported 
activeli'  b}'  the  operational  command,  as  well  as  by  such  other  available  exrier- 
tise  that  can  be  brought  to  bear  bv  the  Program  Office,  prior  to  issuing  the 
validation  phase  RFP.  L.\Tiress.ed  simtily,  the  imnortant  Judgment  to  be  readied 
i.s  whether  the  projected  system,  if  further  defined  and  built  to  meet  the 
"eciui remen ts  exactlv  as  stated,  will  indeed  meet  needs  of  the  operational 
rn.spion.  That  judgment  is  necessarilv  an  estimate;  and  it  happens  to  be  one 
which  has  proved,  over  the  historx'  of  svstem  programs,  to  be  subject  to  a  svs- 
tematic  bias:  Further  wer'k  as  the  program  moves  dmsr.stream  inevitahlv  rcs-uJis 
fr  s  better  widerstandina  cf  technical ,  cost,  and  time  implications  cf  the 
re-re' remente  as  originally  stated,  and  in  discoveries  of  ney  rrea"' rrm-r'  -.s  ■■  'v 
yrr-'-inucly  iderr  '  fied — I'iisrgs,  resulting  in  expansion.  That  phenomenon  has 
long  been  the  chronic  and  major  cause  of  cost/schedule  overruns  and  program 
failures.  To  exT'^ect  that  its  effects  can  be  eliminated  completely  is  unreal¬ 
istic.  But  It  represents  the  principal,  known  source  of  risk  in  electronic 
svstem  rnegram.'-  which  a  I'alidation  nhase,  if  properlv  planned  and  managed,  can 
reduce  tc-  an  acceptable  level. 
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Rciatccl  pri.-narat ion;'  to  be  accomplished  durinp.  this  period  include  the 
e  1  i  ov;  1  r,  c  a  c  t  i  \’  1 1  i  c  s ; 

Ihi^iatinp.  coordinatinp,  and  issuine  the  Propram  Hanapement  Plan  fPMP) . 

"reparation  and  release  or  the  Rr'i^  packape  to  potential  contractors . 

dentractor  rireparal ion  of  validatjon  phase  proposals. 

■•v.ari'.  of  validation  phase  contracts,  based  on  proposal  evaluations  and 
so'ar'c-  selection  procedures. 


Tile  svsieir  specification  is  included  in  the  RFP  as  a  part  of  the  statement 
f  '••''r'K  ,  tnpct'ner  with  requi  renent  s  for  its  further  analysis  and  oran- 

le:'.  ^\’  the  ’,m  !  iuat  ion  phase-  c:ont;  actors.  lenerail'-',  The  c.andidatf  contract..':' 

ii.'ivt  'pveettd  'Efforts  in  studie'-  cf  '^ho  nropram  prie.-  tc  receipt  of  the 
ff;  Menca-,  sinc^  thev  must  aJ.se  pcrfo’ni  further  anaJy.'-es  durinp  the  process 
f  prenarinp  proposals,  the  successful  candidates  shoulu  liave  accrued  a  sub- 
taiitial  kivnuTedcc  of  the  ri'or.ra;:  b-,-  the  tim."  the  ne.xt  tie'^iO'd  becins. 

'"ti  anpineer Inp  tiocrjiirntat  ion  ipcornorated  as  -'irTri  renut res'ents  in  the 
i.T.  spei  1  ficiit  ion  -.para.  .'1  l.-t‘  will  normal  I'.'  oor.si.st  crd;r  uf  selet 

s  '.  (.'!'*  io:r  o-'  tie.  diocunicnt at  ion  rener.ated  durinp  earlier  studies  ;set-  _.t.l 

ben-','  .  rlp>.’r-'''ar ,  tlr  sli-oulc;  preiiare  a  list  of  document."  whn'li  hn'.c  a 

re.r  bearinp  cm  tiv.  s.i’stoi:!.  including  conceptual  phase  studies,  :tnd  provide 
T,  ic-'  .'’f  tiie  list  '.•'ith  the  Rh!\ 


'1 '.cr  i;  i  .on  a-si:iiie<- .  for  .<■  inii)]  ici t'.' ,  that  the  si'.ster,.  i tr  IX'  proco.re.: 
iatoi'.  iarinp  l'iil-;-saJe  de\ cloirienT  ■  t'nrouph  :i  sinple  prime  .-or.rr.actor . 
!'PU',",'e:'.  :t  ni.T'  lv  a  I'iable  option  in  some  P’'Ocrai7is  to  use  as'mci'ite  contrac- 
'  or  -  1  .'o  separate  ''o  stem  se'cment.s.  In  tiiat  case,  the  s\-:^tev  spec:  ficat  ion 
■  1:  na' ;■  iiee:!  pret'.'ireil  in  the  fen-  of  oiu'  ponerai  wiluo  '  .and  sc]riratc  I'clum-s 
■r:  secmei.ts;  and  competition,  durinv  validation,  would  oe  p\'  coit.petinc 

i:c  s  ■  .  "Ck'hnica!  activities  slinuid  ir  iia.'icaii"  .^iriTir  *e  the  liccree 

tfCit  c  .si.’-au-nt  -  c.an.rstiriL’  in  itself  of  .srp.irate  runfional  area.s  - -rerits 
:  ’..M'.ibh  aiir-roach  to  its  .analysis  aad  desini. 
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Imulenentat  lor. 


Descriptions  provided  below  of  technical  activities  performed  b^'  contrac¬ 
tors  durinp  this  period  follow  the  sxTioptic  outline  of  events  depicted  in 
rigure  i-5.  Acti\’ities  shown  in  the  figure  are  limited  to  those  leadinc 
direct  1\'  to  maior  products  mentioned  earlier  relating  to  the  s>’sten‘  sr)ecifica- 
taon,  item  specifications,  and  program  plans.  It  is  conceivable  that  reason; 
could  exist  tc  reauire  a  prototype  (i.e.,  nartial  protot\T>e t  demonstrati  on  as 
a  part  of  this  phase.  In  that  event,  there  would  be  additional  acti\'ities 
who  da  would  interact  with,  but  should  not  replace,  these  mainline  act i\'] ties. 

This  phase  as  a  whole  is  described  below  as  consisting  of  three  successive 
stapes:  a  first  stare  devoted  to  meeting  technical  o:'dectives  re.^'lected 

in  reauirements  for  the  System  Requirements  Rei'iew  fSRR);  a  second  stage  which 
term.inates  with  successful  completion  of  the  System  Design  Rei'iew  (SDRi;  and, 
a  ;'inal  period  during  which  contractors  complete  and  submit  all  products  for 
this  phase  recuired  by  their  contracts. 

1 . 5 . 1 . 1  System  Definition 

The  contractor's  efforts  at  this  initial  stage  should  be  devoted  to  expand¬ 
ing  the  svstem  engineering  studies  described  above  for  the  conceptual  ])ha.sc- 
f2.4,li.  Tne  technical  approaches  should  be  basically  similar;  however,  the\’ 
are  now  guided  bi’  firm  decisions  reflected  in  the  initial  si'stem  specification, 
and  by  known  requirements  (stated  in  the  SOV.')  for  studies  in  specific  areas 
indicated  by  results  of  the  earlier  work.  Hence,  while  the  contractor  should 
study  and  understand  the  mission,  functional,  and  performance  analyses  accom¬ 
plished  previously  at  the  higher  levels,  he  should  not  be  required  to  iterate 
those.  The  major  emphasis  at  this  time  should  be  placed  on;  fa'  ex-panding 
the  analvsis  of  functions  to  lower  levels;  (bi  determining  design  requirements 
for  the  system  segments;  fc'  perform.ing  trade  studies  to  evaluate  both  func¬ 
tional  and  design  solutions;  and  fdl  arriving  at  allocations  of  the  reauire- 
ments  to  identified  hardware  and  software  item.s  w'ithin  each  svstem  segment. 
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SNVia  .L'o'JX  '3  IJvU  y  1.3 


The  purpose  of  SPK  is  tc  review  and  evaluate  the  contractor's  propress  in 
accomplishing  tnos-'  tasks,  as  they  contribute  to  specifving  functional  and 
physical  characteristics  of  the  system  as  a  whole.  As  indicated  in  Figure  2-5, 
the  last  step  mentioned  is  probably  the  most  visible  single  indicator  of  whether 
the  SRR  objectives  are  being  met.*  The  system  snecification  will  not  be  full^■ 
completed  until  all  items  can  be  identified  (in  paras.  3.1  and  .’.1.4)  b^•  fl 
number  or  equivalent,  approved  nomenclature,  and  specification  number.  The 
total  listing  will  identify  all  commercial  and  Government  inventor>'  as  well  as 
developmental  items,  and  all  items  required  for  sunport  as  well  as  for  opera¬ 
tional  functions  of  the  system.  Some  of  the  minor  items  need  not  be  precisely 
identified  until  later.  However,  the  list  should  be  complete  at  this  point  in 
t.he  program  with  respect  tc  all  items  upon  which  the  ensuing  validation  phase 
activities  are  dependent.  Those  include  both:  (al  existing  items  (e.g.,  com¬ 
puters,  consoles,  and  major  items  of  support  software)  which  affect  the  content 
of  subsequent  studies  and  planning,  and  fb)  items  of  new  development  for  which 
development  specifications  are  to  be  prepared  during  the  next  stage. 

Evaluation  of  the  proposed  hardware/software  configuration  for  each  segment 
should  be  based  on  consistency  with  documented  design  requirements  derived  from 
the  functional  allocation  and  trade  studies,  and  on  con^liance  with  management 
criteria  set  forth  in  such  sources  as  AJFSCP  800-7  and  MIL-STD-483.  Those 
sources  recognise  that  the  item  .selection  process  is  largely  a  matter  of  judg¬ 
ment,  involving  experience  and  awareness  of  the  relevant  technical  and  manage¬ 
ment  considerations.  However,  the  established  criteria  for  the  selection  of 
"configuration  items"  tend  to  apply  most  directly  to  items  of  new  development. 
Some  special  questions  encountered  in  dealing  with  mixtures  of  commercial  and 
developmental  elements,  which  have  been  characteristic  of  electronic  svstem 
program:-  in  recent  years,  are  discussed  in  the  next  section  (see  3.2). 


*A1 though  referred  to  here  as  a  single  event,  SRRs  may  be  scheduled  on  succes- 
si\'e  calendar  dates  to  correspond  with  expected  progress  (a)  initially,  in 
defining  the  system  configuration  for  operational  functions  and  (hi  later,  in 
defining  derived  requirements  in  such  areas  as  logistic  .support,  facilities, 
the  sped  pity  d  isciplines  (reliability,  maintainability,  ...),  engineering 
intecnirion,  and  rest  pl;inning. 
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Z.S.2.2  ConfieiiratioTi  Item  Definition 


Thf  i(ientific3T ion  of  item?  accomplished  in  the  precedine  stape  represents 
the  completion  of  desipn,  as  such,  at  the  level  to  be  specified  in  the  svstem 
specification.  Iterations,  refinements,  and  some  expansions  of  the  system 
specification  should  continue  to  occur  throuehout  tne  remainder  of  this  p.nase. 
However,  the  principal  focus  of  the  system,  engineering  effort  as  a  whole  shifts 
at  t  lis  point  to  concerri  with  requirements  for  the  individual  items.  In  gen¬ 
eral,  maior  technical  activities  are  now  devoted  to  supplementing  the  svstem 
specification  with  item-level  specifications  and  other  documents  which  expand 
the  definitions  of  requirements  allocated  among  the  identified  system  compo- 
nents-'including  persorjiel  and  facilities  as  well  as  hardware  and  software. 

The  varied  and  interrelated  activities  which  should  be  completed- -or  nearly 
cormpieted- -bv  the  time  of  SDR  include  those  suimarited  ver>’'  briefly  below: 

a.  Generation  of  the  allocated  baseline.  Tne  most  prominent  act ivitv  during 
this  stage  is  conceitied  with  developing  or  acquiring  the  complete  set  of 
item  level  specifications  which  will  constitute  the  svstem  allocated  base¬ 
line  when  completed  and  approved.  Tlie  allocated  baseline  encompasses  the 
total i tv  of  system  requirements  allocated  to  items  of  harnvs’are,  software, 
and  facilities,  it  is  documented  in  the  form,  of  specifications  which  will 
be  placed  on  contract  during  the  next  Phase  of  the  program  to  govern  the 
development  or  other  acquisition  of  those  items.  As  identified  in  the 
svstem  specification  (i.e.,  in  the  .specification  tree.  para.  a. 1.4),  those 
ma\'  include  most  or  nearl>'  all  of  the  following  tv^ies  and  forms: 

IT  Computer  Pi'ograni  r>cvelopment  Specification  (Ti-pe  B5) .  By  and  large, 
most  of  the  operational  functions  of  an  electronic  system  are  allo¬ 
cated  to  computer  programs.  The  process  of  generating  a  B5  specifi¬ 
cation  in'.'olves  further  analysi.s  of  the  allrcated  fimctions  to  much 
lower  levels  than  The^'  are  specified  in  the  s\'stem  .specification.  In 
-erms  of  total  time,  manpower,  bulk  of  essential  detail,  and  direct 
significance  to  tne  operational  mission,  th-i,--'  task  should  normally 
.account  for  most  of  the  system  en.gi  nee  ring  effort  expended  during  the 
validation  phaj'o  as  a  whole. 
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f21  Hardware  Development  Soecifi  cat  ions.  .-Mthouph  electronic  svstem 
nrograms  do  not  t^^ically  include  the  development  of  niaior  item.s  of 
new  aerospace  equipment,  there  are  nonnallv  some  items  to  be  nev.lv 
developed  for  undergo  major  modification,  e.g.,  a  console  or  communi¬ 
cations  element!  which  require  the  preparation  of  development  speci¬ 
fications.  rienending  on  the  item  complexit>'  and  other  factors,  the 
specifications  prepared  at  thi'^  time  will  be  Tvne  fl  fPrime  Ite- ' . 

Br  (Critical  Item;,  or  B.'  (Non-Comnlex  Item'. 

(3!  Facility  Specification  fTvpe  B4).  The  .system  soecif icat ion  identi¬ 
fies  facilities  with  respect  to  intended  use,  general  characteristics, 
and  status- -i  .e.  ,  vAether  existing,  to  be  modified,  or  to  be  neiv]v 
constructed.  The  preparation  of  a  T^rie  34  soecif icat ion  is  initiated 
at  this  time  for  facilities  requiring  new  construction  or  major  modi¬ 
fications.  Requirements  are  derived  largely  as  a  part  of  the  on-going 
analyses  of  requirements  for  system  eauipment  and  persomiel. 

(4)  Other  Specifications.  In  terms  of  numbers  alone,  most  of  the  speci¬ 
fications  to  be  preoared  or  acquired  at  this  time  are  likely  to  be 
for  existing  items  of  hardware  and  software.  Depending  on  sources  and 
other  factors,  these  will  include:  Tx'oe  C4 ,  for  items  already  in 
Government  inventon';  specifications  to  comonercia]  practice  ("‘'T!.  S-S.'400 
Form  2  or  Form  3);  or  product  function  specifications,  Ti-oe  Cl;;  or  C2a. 
Although  classed  as  "product  specifications",  these  should  general 1\' 
be  anproved  and  controlled  as  part  of  the  allocated  baseline  fo’'  the 
reason  that  they  constitute  the  onlv  requirements  documentation  tc 
govern  the  acquisition  of  the  items  during  full-scale  develo’-'mer.t . 

Personnel  and  training  requirements.  This  activity  consists  of  develoninc 
information  relating  to  numbers  and  tvnes  of  nersonnel  needed  for  *^10 id  ;ind 
organizational  operations  and  maintenance,  and  to  projected  needs  for  indi- 
'.'idual  and  team  training.  Earlier  estimates  of  nersonnel  retiuiremer.ts  arc 
rc'fined  during  this  neriod  largelv  on  the  basis  of  data  derived  fro’n  the 
on-goinc  analyses  of  requirements  for  eouipment  and  eomnuter  nroyrac-  (Ds, 
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supplemented  hv  .-idditional  analvsis  nonr,allv  required  to  develop  the 
standard  Qualitative  and  quantitative  nersonnel  requirements  information 
'QOl’RI)  report.  Depending  on  the  svstem,  significant  additional  efforts 
ma\'  be  involved  in  developing  requirements  for  capabilities  that  can  be 
used  bv  the  operational  command  to  perforir,  simulated  exercises  for  pur¬ 
poses  of  system  training  and  evaluation. 

c.  itemi- level  development  and  test  plans.  Technical  planning  for  the  de\'el - 
opment  of  nev.  Cls  and  CPCIs  should  be  accomplished  in  parallel  with  the 
svstem  engineering  analvses  being  performed  to  develop  the  Tvpe  P  speci¬ 
fications.  This  activity  normially  involves  conducting  preliminary  studies 
of  hardware  or  software  desigii  for  each  item,  which  should  be  carried  out 
during  this  phase  in  sufficient  depth  to  provide  a  basis  for  '11  evaluating 
t'ne  impact  a,nd  feasibilitv  of  detailed  performance  requirements  as  they  arc 
formulated,  cUid  (2)  determining  schedules  and  resources  needed  for  each 
item's  development  during  the  next  pjhase.  InteiT>al  test  plarjiing  is 
included  in  the  development  plans.  Separate,  preliminarv  plans  for  Cl  and 
C^CI  qualification  should  be  developed  concurrently  and  in  coordination 
with  test  requirements  being  documented  in  .Section  i  of  the  B-t>T>e  speci¬ 
fications  . 

d.  Svstem  integration  and  test.  Significant  continuing  activities  at  the  sys¬ 

tem  level  arc-  concerned  with  requirements  and  plans  in  the  areas  of  system 
and  svstem  se.gment  interfaces,  site  installation  and  checkout,  and  system 
development  test  and  evaluation  (■DTSbl .  Pv  the  end  of  this  phase,  func¬ 
tional  definitions  of  all  svstem  iind  inter-segment  interfaces  should  be 
completeCi  .and  incor;voratcd  into  the  svstem  specification,  together  with  all 
definitions  at  lower  levels  which  exist  as  predetermined  constraints  I'cf. 
2.4.1  above,  ilocK  .".ll-...  Following  tht  completion  and  'verification  of 
performance,  desien,  .and  interface  reciuirements  in  Section  .’'i.  Section  4 
must  be  completed  to  snecifi’  methods  and  levels  of  DTf-F  to  be  em'oio''oc;  in 
\'crif\’ing  tliat  ttiose  re'iui rements  are  met.  As  a  part  of  tiiese  actiiities. 
associated  I'lan^  are  prepared  for;  interface  control  ourinc  the  develop¬ 
ment  'iiia:-t  for  equipment  .and  facilities  :  ^irc  ecuipment  instal¬ 
lation;  and  inf.t 


46 


The  SDR  is  conducted  before  this  stage  ends  to  revuev  requirements  of  the 
uodated  system  snecification,  specifications  of  reau:rements  allocated  to  con¬ 
figuration  items,  and  the  contractor’s  accornnlisliment  of  svstem  engineennc 
management  ohiectires.  System  engineering  studies  siiould  ha^'e  been  performed 
as  reauired  bv  the  SOW- -and  by  the  nature  of  auestions  encountered  durinr 
nrogress  of  the  worlc--,  cither  separately  or  as  inherent  narts  of  the  activitie:- 
described  above. 

At  the  system  level,  the  emphasis  at  SDR  is  placed  on  adequate  coverage  aiid 
assessment  of  system/systeTT'  program  characteristics  in  .‘^uch  areas  as  integrated 
loeistic  support,  standardisation,  growth  capabilities,  life  cvcle  costs,  and 
other  special  topics  listed  in  Appendix  B  of  I'lL-.STD-lSdlA,  as  anplicable  to 
the  given  program.  Objectives  are  similar  to  those  of  the  precedinc  SRR,  but 
with  attention  at  this  time  to  comprehensive  coverage,  completeness,  and  integ¬ 
rity  in  the  light  of  lower-level  studies  of  requirements  allocated  to  the  svstem 
elements.  Information  required  in  final  font,  pertaining  to  th^  specification 
tree  and  Cl  lists  fin  paras.  3.1.4  and  3."  of  the  system  sppci fication)  should 
be  fully  complete  bv  SDR,  including  specific  identifications  of  all  equinmert 
and  computer  programs  required  for  support  as  well  as  for  mission  operations. 

•At  the  item  Level,  a  significant  purpose  of  SDR  is  to  review  the  specifica¬ 
tions  proposed  to  constitute  the  system  allocated  baseline--for  iormat,  content, 
technical  integrity,  traceability  to  system  misrion/support  reouirements,  and 
correlation  of  requirements  across  the  full  set  of  items.  The  general  ernhasi.: 
of  this  review  is  on  verifying  that  the  contractor  has,  in  fact,  succes':^ull' 
translated  system  requirements  into  individuallv-defined  sets  of  reoi: . .emont.'^ 
for  the  system  hardware  and  software  elements.  Critical  requirements  to  be 
examined  for  data  processing  and  special  communications  equipment  sterns  relate 
to  speeds,  capacities,  compatibility  with  the  projected  nature  and  structure  of 
system  computer  programs,  and  secondan'  characteristics  in  such  area.s  as  opera¬ 
bility,  electromagnetic  compatibility,  reliabilitv,  and  ^:;^intatnabilit^7availa- 
bilitv.  For  computer  programs,  particular  attention  is  t%Tiicallv  needed  to 
examining  fa)  system  engineering  documentation  generated  in  the  process  of 
deriving  requirements  for  the  mission/operational  CPCI ( s )- -together  with  related 
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requirements  for  operational  personnel  and  interfacing  equipment  characteris¬ 
tics  (e.g.,  detailed  operating  characteristics  and/or  layouts  of  displays  and 
manual  input  devices)--,  and  fb)  technical  integrity  ajid  completeness  of  the 
T>T3e  B5  specifications  themselves.* 


2 .  S .  3  Ev^aluation  and  Decision 

This  final  period  of  the  validation  phase  is  devoted  to  reviewing  and 
evaluating  contractor  products,  updating  program  planning  documents,  and 
accomplishing  related  actions  required  for  the  milestone  II  decision. 


Contractor  products  to  be  e\'aluated  consist  of  technical  and  planning  data 
items  delivered  against  the  validation  phase  CDRL.  The  total  package  of  data 
submitted  by  each  contractor  should  include  items  in  the  following  categories: 


--Updated/expanded  system  specification --in  the  form  of  an  ECP  package, 
containing  specification  change  notices  (SCNs)  covering  exact  proposed 
page  changes  to  the  specification. 

--Allocated  baseline  documents- -the  full  set  of  development  soecifications 
(or  their  equivalent;  see  2. 5. 2. 2, a  above)  for  hardware,  software,  and 
facilities  items. 


--System  engineering  documentation --reports  of  functional  analyses, 
reouirements  allocations,  trade  studies,  human  factors  engineering 
studies,  program  risk  analyses,  computer  program  sizing  and  timing 
studies,  per.sonnel  and  training  requirements,  et  al. 


*The  evaluation  of  B-type  specifications  accomplished  at  SDR  is  preliminan-, 
resulting  immediately  in  directions  to  the  contractor  for  correct ions /improve¬ 
ments  to  be  incorporated  prior  to  their  submittal  at  the  end  of  this  period. 
Full  evaluation  of  the  specifications  as  a  basis  for  PO  authentication  (and 
baselining  for  subsequent  configuration  control)  is  accomplished  v'ia  in-house 
specification  team  review  procedures  following  that  submittal.  A  further  dis¬ 
cussion  of  factors  to  be  considered  in  evaluating  the  TApe  B5  specifications 
is  provided  in  another  guidebook  of  this  series  (see  ref. 18,  para.  2.1). 
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--Management  plans  for  full-scale  development --svstem  engineering  manage¬ 
ment  pl;in  (SEMP) ,  computer  program  development  plan  fCPDP),  test  plans, 
equipment /site  installation  plan,  work  breakdown  structure,  and  otners 
as  required  by  the  P.FP  and/or  validation  phase  CDRL  ! for  a  "shopping 
list"  of  these  plans,  see  paragraph  .i-18,  AFSCP  800-?!. 

--Contractor  cost  information  and  recoo'iended  inputs  tc  the  full-scale 
development  phase  SDK  and  CDRL. 

Those  items  should  be  evaluated  individually  against  requirements  estab¬ 
lished  for  each  item  in  the  contract  and/or  RFP.  Tne  system  specification  is 
evaluated  for  continued  adequacy  in  specifying  Air  Force  operational  needs  for 
the  system.  Each  contractor's  proposed  changes  should  consist,  primarib',  of 
expanded  definitions  of  the  system  segment  config-uration-- i .e. ,  in  the  form  of 
Cl/CPCI  lists,  requirements  allocations  to  the  items,  and  schematic  block  (iia- 
grams  depicting  functional  arrangements  of  the  hardware  and  software  assemblies 
Auditioually ,  the  contractor's  SCNs  should  normally  include  proposed  clarifica¬ 
tions  and  expansions  in  other  areas--e.g.,  design  and  construction  standards, 
inter-segment  interfaces,  and  test  requirements  (Section  4')--which  fully  reflec 
his  proposed  approach  to  system  hardware  and  software  implementation. 

fiowever,  the  important  overall  assessment  to  be  made  at  this  point  is 
whether  that  total  collection  of  technical,  management,  and  cost  information 
is  sufficiently  sound  and  realistic  to  warrant  progression  into  the  next  nhase 
of  the  system  program.  Assuming  that  the  system  specification  is  judged  to  be 
adequate  and  complete,  the  burden  of  that  overall  assessment  now  rests  on  deter 
mining  that  (a)  the  allocations  of  system  requirements  to  hardware  and  software 
elements  have  been  soundly  accomplished,  (b)  the  allocated  baseline  documents 
are  adequate,  both  individually  and  as  a  set,  to  govern  actual  acquisition  of 
the  system  elements,  and  fc)  the  contractor's  management  plans  and  cost  esti¬ 
mates  for  full-scale  development  represent,  in  fact,  serious  and  realistic 
planning  based  on  identified  needs  of  this  program. 
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ISSUES  AKT?  PROBLFA1  AREAS 


The  system  specification  is  not  intended  to  be  a  "stand-alone"  documciit. 

As  prescribed  in  the  current  standards,  its  content  reflects  established  con¬ 
ventions  based  on  intended  functions  of  the  svster,  specification  in  relation,  to 
t'ne  many  other  documents  that  arc  t>'picallv  generated  and  used  in  the  course  of 
a  tTOical  system  program.  Generally,  specification  t>T)es  are  distineuus.n-jc  from 
cne  another- -ajid  from  such  other  documents  as  plans,  manuals,  reports,  etc.-- 
on  the  basis  of  such  factors  as  scope,  nature  of  technical  and/or  management 
content,  phasing,  sources,  and  intended  uses.  However,  the  structure  of  docu¬ 
ment,-  in.  a  large  svsteti  nrograii'  tends  to  be  sufficiently  comple.x  and  variable 
that  those  distLncfions  are  not  always  obvious.  Purposes  of  the  discussion.'- 
provided  in  this  section  are  to  summarize  intended  functions  of  the  svstem. 
specification,  a.-  t.hose  arc  stated  or  implied  in  existing  standards,  and  to 
identify  a  fev;  problem  areas  whicli  have  proved  to  be  prominent  sources  of  diff''  - 
cuitv  and/or  disagreement. 

■’ •  -  bummar)’  of  System  Specification  Functions 

Tradirionallv,  snecifications  are  documents  which  define  the  required  char¬ 
acteristics  of  Items,  proces.ses,  or  materials  to  be  developed  or  produced  and 
delivered  by  a  contractor.  The  specification  is  normal])-  referenced  in,  ^ind 
functions  as  a  part  of,  a  contract  statement  of  work.  AEile  the  specification 
1)^365,  forms,  and  uses  prescribed  in  current  military  standards  conform  gener- 
all'.’  to  traditional  Government  and  industiy  practices,  they  have  been  influenced 
significantly  b)-  considerations  derived  from  the  special  circur'LStancc-s  of  s^■ste^ 
ac'uuisition  programs.  It  is  also  pertinent  that  the  standards  we  h.ax^e  Toda3’-- 
i.c.,  those  contained  in  ''IL-S-S.^sPh  and  MJL-STD-490--are  largel)-  based  on  -Vir 
'"orce  .‘■■vstems  management  policies  that  were  in  effect  during  the  earl\-  and 
mid-’.^bPs.  The  standards  have  not  changed;  but  some  questions  do  arise  as  a 
res'ilt  of  continuing,  substantial  changes  which  have  occurred  since  that  time 
in  the  policies  an.’  circumstances  of  system  acquisitions. 
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•ac  stnutarc  o:  iprocram-pecuiiar i  sne^i i icat !0^^ 
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c:  natenci.  The  basic  principle  which,  differentiates 
froc:  item- level  s-ieci f icat ions  was  once  ex^iressed  in  : 


ne  concept  c'l  the  unitora;  spec: ;  icat  ion  oroprar. 
fact  that  s\st‘en;s'ec;'ainnent  are  not  procured  '"'i' 
s\’stenis  but  rather  h\'  separate  end  iten?  of  contractc 
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Tile  diirect  and  significant  implication  of  that  statement  is  that:  .fontrac- 
tnrs  can  to  raJe  fullv  responsible  for  the  dev'elopment  and  supnl'e  of  end  items, 
;r.  accordance  witii  item- level  specifications  wiiich  are  made  nan  of  their 
contracts,  d..'  jr^Ktracr.  ‘r?-  aye  not  oi'.igated  t'  jc:  :>ia~  tue  susze”'  meetc  .-c.'" 
-''.’■.‘c  “i.  .'cj*  I’pcc;  *he  rcapotieirilitu  for  aomr ::  anoi.  v:th  rhe  eyezerr.  spcaifiaa- 
ur  u  M'-Z-:  r;;no'Z>.'  uZ Th  the  Air  i-'orae  vroaurir.y  activity,  further  iix'-lica- 
tions  of  that  principle  are  amplified  in  tne  following  summ.aries  of  system-  vs. 
iten  -'.evel  spvci  ficat  ion  functions  during  the  course  of  a  svstem  proeram. 

.  i  .  i  he;  at  ions  of  leclinical  to  Mnnauement  Factors 


The  focal  products  of  contractors  to  be  specified,  manaeed,  and  accented 
diirinc  a  s''ster’  proeram  consist  of  identified  items  of  hardware  and  software-- 
eenerallv  referred  to  as  conf  ipura'.  ion  items.  A  few  of  the  established  rules 
which  rei:ite  to  uuestions  at  hand  are  as  follows; 

a.  .'•.ithcuei.  special  provisions  arc  made  for  some  hardware  components  ("criti¬ 
cal  items"!  whicii  mav  be  specified  scnaratelv,  the  snecification  "tree" 


*  Me.  d!,ap'.ei  1  of  tht  i'ottk  r  AF.SC  '^ianuai  f-f  1 ,  donfi  (.nirat  ion  'lanacement  iKirin, 
:  Acciiis  it  loii  Fiiasf,  dated  1  .Tune  I'.H'Z.  The  unifoiT,  sncci  ficat  ion  progra- 

referred  t<  i -■  t'ne  effort  which  led  to  tiie  "-t  rucTure  no'v  standardized,  in  "li- 
,'ipii  'hi  -'T',.- 1':'!''.  Prior  to  tii.nt  effort,  tijere  was  a  proliferation  of 
sped  fications  with  diverse  titles,  formats,  coveraee,  and  usc.s. 
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coii?ist?  basicallv  of  onlv  two  levels--nai!ielv:  1  >  the  ‘^vstern  levc’.  and 

!  the  iter:  le\'el.  Ttie  fcm  of  a  sriecification  tree  to  be  rrovideu  in  l!ic 
systen.  specification  (in  para.  .v.l.-M  is  illustrated  in  Fipure  o-l. 

That  specification  stmeture  must  be  capable  of  coverine  the  acquisitior^ 
of  all  hardware  and  software  needed  in  the  svstem.  However,  it  docs  not 
ha\’c  xn  obvious,  one-to-one  correspondence  with  the  hierarch'.’  of  hardware' 
software  assemblies  which  is  tiTiicall}'  generated  as  a  result  of  engineo’-irr. 
analysis  xnd  design.  Figure  ?-2  illustrates  a  (partial;  sample  of  the 
latter,  which  represents  the  immediate  teclinical  nroduct  of  conceptual  and 
validation  phase  analvses  described  previousl^■.  Hssential  "correlation"  of 
that  breakdown  witii  the  specification  tree  is  nevertheless  achieved  hv 
I'irtue  of  the  facts  that: 

fl'  The  top  three  levels  represented  in  this  diagram  are  levels  of  assembiv 
to  be  defined  di recti v  in  the  svstem  specification. 

'2'!  Assemblies  at  the  fourth  level  nav  all  be  identified  and  specified  as 
separate  CIs  (except  that  the  Computer  Programs  block  shown  in  this 
sample  w’ould  be  likely  to  consist  of  separate  CPCIs  at  the  ne.vt  lower 
level! . 

■T"i  Assemblies  at  lower  levels  may  be  specified  either  as  separate  or 
as  components  of  the  larger  CIs  into  which  they  assemble.  For  e.xainple, 
the  Power  Supply  (fifth  level)  could  be  identified  as  a  separate  Cl 
because  it  is  to  be  Government -furnished  or  procured  from  a  vendor. 

Thus,  the  Cl  concept  functions  to  define  a  contracting  level,  somewhat 
indenendently  of  the  technical/assembly  relationships  of  the  items  speci¬ 
fied.  That  is,  the  designation  of  a  "Cl"  applied  to  a  given  assembl>'  of 
hardware  or  software  components,  of  whatever  size  or  comrilexity,  defines  a 
level  of  m.anagement  as  between  the  procuring  activitN’  and  contractor  wiiich 
involves,  for  example;  one  specification,  one  set  of  technical  design 
reviews  and  configuration  audits,  one  test  (qualification)  program,  and 


53 


one  set  cf  support  documentation.  It  is  the  level  of  delivem-  and  accep¬ 
tance.  accountabilitv.  and  provisioning  for  locistic  support. 

In  the  framework  of  that  established  model,  assurance  that  requirements  for 
integrated  performance  of  assemblies  at  the  functional  area/s>’stem  setment ' 
svstem  levels  will  be  met  rests  heavily  on  provisions  for  controlling  .nter- 
faces  among  the  CTs.  "Interface  control"  is  most  often  thought  of  as  a 
prominent  activit\  of  narticinat ing  contractors,  carrieci  out  principallv 
during  full-scale  development.  However,  the  only  real  control  contractors 
can  exercise  at  that  stage  is  over  their  in-process  designs  of  ecrjinment 
items  at  the  product  level --to  meet  requirements  and  constraints  established 
in  their  contractual,  allocated-baseline  specifications.  .Actual^',  the 
accepts  primar>-  responsibility  for  interface  compatibilitv  among  Cls  at  the 
time  the  Cl  performance  (allocated  baselinel  specifications  ajc  apj'roved  anc 
Placed  on  full-scale  development  contracts.  The  assumption  is  that  neas'.jre; 
have  already  been  taken--prior  to  and  during  the  validation  pha5e--tn  a.s.sure 
that  interface  requirements  were  svstematically  and  comprehensive^-  identi 
Tied,  analyzed,  allocated  to  CIs,  and  properly  incorporated  into  tlio  Cl 
specifications . 


3.1.2  Suritnary  of  System  Specification  Functions 

.As  indicated  above,  the  system  specification  is  a  document  which  governs, 
primarily,  the  PO  itself.  It  does  have  some  uses  as  a  contracting  instrument, 
however,  within  the  established  fnimework  of  system  acquisition  management  pro¬ 
cedures.  The  following  summarv  includes  mention  of  those,  together  with  note'= 
to  indicate  their  recognized  limitations. 

a.  Program  Requirements  Baseline.  The  system  specification  begins  to  function 
at  the  time  it  is  initiallv  prepared,  coordinated,  and  approved  hv  HC  USAF 
as  a  part  of  the  PO's  "charter"  for  pursuing  the  program.  It  defines  the 
tPcimical  portion  of  the  program  reouirements  baseline,  which  also  includes 
the  documented  operational  concept,  logistics  concept,  and  cost  estimates. 
Significant  changes  in  broad  objectives  defined  in  those  documents,  later 
in  the  program,  reciuirc  IKj  U.SAP  review  and  approval, 
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b.  Fiinc 1 1  ona I  Baseline.  As  described  above  (2.5.1J,  the  s\'sterr,  s]K'c:ficatioi. 

IS  established  as  the  functional  baseline  for  formal  conf ijairat ion  control 
hv  the  Propram  Office  CCP  hv  the  time  it  is  issued  with  validation  phase 
RFPs.  Probably  its  major  single  function  in  the  life  of  the  program  is  to 
ser\'e,  during  that  phase,  as  the  basis  for  program  planning  and  the  deriva¬ 
tion  of  lower-level  requirements  for  svstem  personnel,  hardware,  software, 
and  facilities.*  But,  since  it  continues  to  sen^c  that  and  other  signifi¬ 
cant  functions  identified  below,  it  is  systematicallv  controlled  thereafter 
and  maintained  to  reflect  the  nnpact  of  all  approved  changes. 

c.  System  Test  and  .Acceptance.  ViMle  contractors  normally  provide  substantial 
supjiort,  the  planning  and  conduct  of  system  DT§E  is  a  Program  Office  respon¬ 
sibility.  .System  DT&E  is  planned  against  requirements  stated  in  Section  4 
of  the  system  specification  and  conducted  to  verify  that  the  integrated 
collection  of  svstem  elements  will  in  fact  meet  the  performance/design  and 
interface  requirements  set  forth  in  .Section  5.  Acceotance  of  the  system  by 
the  operational  command  is  based  principally  on  successful  accomplishment 
of  svs'^em  DT5L. 

d.  Total  .System  Procurement.  The  assertion  has  been  made  that  the  Air  Force 
should  acquire  each  system  "as  an  entity"  from  a  single  contractor,  using 
the  system  specification  as  the  contractual  compliance  document.  Program 
Managers  do  have  the  flexibility  and  obligation  to  tailor  each  program 
according  to  its  needs;  and  there  are  understandable  motives  to  depart  from 
the  practice  of  procuring  solelv  at  the  Cl  level  (see  3.2  herein).  How’ever, 
the  svstem  specification  is  not  designed  for  that  application.  Some  of  the 
pertinent  considerations  are  mentioned  elsewhere  in  this  discussion.  Addi- 
t  lonall^■ : 

'll  The  accepted  acquisition  management  standards --throughout  such  areas  as 
configuration  management,  design  reviews,  test  programs,  and  acceptance 
--are  based,  by  and  large,  on  the  established  differentiations  of 

*At  one  time  in  the  histor'/  of  system  programs,  that  was  the  only  real  function 
of  a  svstem- level  specification.  After  that  initial  use,  it  was  often  simplv 
replaced  by  the  other,  derived  documents. 


^'0  rind  contractor  responsibilities  for  the  svsten-  as  a  v.n^le 


firuration  fond',  items.  Turrent  standards  associate..!  with  •'Vl'P.  -■ 

series  procedures  provide  little  or  no  ;niidancc  or  s'annoit  for  a  ‘ota 
systeir.  procurement. 

2!  Figure  presents  a  summam'  overvieu  of  s\'s'^eri  sT'C'ci  fication  fun.' 
tions  in  eoveininc  both  the  on-going  svstcp'  nrograri  anc  the  s\'ste'v 
itself  as  a  complex  end  product,  -is  indicated,  elements  of  the 
resulting  system  are  acquired  individually  through  the  use  of  lower- 
level  specifications.  However,  some  of  those  essential  element.s  of 
the  teta'i  .system  are  ones  which  a  prime  contractor  to  the  PC  cannot 
furnish,  .and  wliich  the  Pf'  it.self  can  control  onli'  within  limit.s  of  :t 
designated  .A.ir  Force  authority.  As  notable  examples: 

3:  The  PO  can  control  reciuirements  for  svstem  facilities  tnat  are  docu- 
nented  in  i'\Tie  F.4  specifications.  But  actual  facilities  acuuisitiori 
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Tgure  3-, 3.  Summarx’’  of  System  Specification  Coverage  and  Functions. 


imilitar>'  construction  proprajni  must  be  accomplished  bv  the  AiTn\-  Corps 
of  Engineers  or  Naval  Facilities  Command  (NAiTAC)  through  contracts 
administered  by  those  agencies. 

The  PO  can  also  control  the  development  and  dissemination  of  docu¬ 
ments  which  detail  requirements  for  the  selection  and  training  of 
sN'stem  personnel.  However:  manpower  allocations  must  be  made  by  HQ 
MS\F;  and  personnel  are  actually  selected,  trained,  and  assigned  by 
ATC  and  the  operational  command.  --This  is  by  no  means  a  negligible 
consideration.  Deficiencies  in  trained  personnel  have  been  known  to 
cause  system  failures. 

e.  Item  Procurement.  The  svstem  specification  is  classed  as  a  "general"  speci¬ 
fication,  covering  characteristics  which  are  common  to  an  identified  class 
of  items  (in  this  case,  items  classed  as  parts  of  a  given  system),  whereas 
the  specification  for  a  single  item  is  classed  as  a  "detail"  specification. 
In  that  role,  it  does  normally  sen^e  as  a  supplement  to,  and/or  as  a  part 
of,  the  contractor's  prociireroent  specifications  for  end  items.  Thus,  in  the 
detail  specification  placed  on  contract  for  procurement  of  the  item,  some 
requirements  mav  be  stated--in  the  item  specification  itself--by  reference 
to  appropriate  paragraphs  of  the  system  specification.*  However,  the  PO 
must  take  care  to  assure  that  the  referenced  requirements  are  identified 
specifically,  and  that  they  do  not  conflict  with  other  provisions  expressed 
directly  in  the  detail  specification.  Orders  of  precedence  listed  in  the 
SOV.'  and/or  specifications  notwithstanding,  contractors  must  normally  obsen^e 
lower -level  requirements  whenever  they  conflict  with  requirements  stated  at 
more  general  levels  or  in  higher-level  specifications. 

f.  Contractor  .Sen'ices.  Tlie  process  bv  which  contractors  deri\T  program  plans 
ajid  lower -level  requirements  for  system  elements  from  the  initial  svstem 

SI  e-C! ficat ion  was  outlined  in  2.5.2  above.  The  system  specification 

examples,  see  i.ii  Ml  I.-STn-4M0,  p.aragraph  2().,5.3.(i  fspecifx’ing  "Safefv"  for 
a  pr.im('  equipment  item)  ;ind  (b)  MIL-.'5TD-48.5,  Notice  2,  paragraph' 60.5.5.4 
( i^pec  i  f'-inp  "Human  I’erformance"  for  a  (TCI).  T1)C  latter  happens  to  be  an 
uTWouru!  exami'le,  incidental  Iv,  hut  for  reasons  unrelated  to  the  present  dis- 
.ussion;  see  r^’ference  IS,  paragraph  5.12. 
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functions  durinc;  that  phase  as  a  compliance  document  in  the  sense  that  con¬ 
tractors  are  bound  to  be  consistent  with  its  requirements,  but  not  ii'.  the 
sense- -normal  to  contract  specifications --that  the  contractors  must  dcl’.vei 
a  set  of  validation  phase  products  which  meet  those  requirements  (namci'-, 
the  s>’stem  itself).  At  that  stage,  contractor  products  are  defined  directly’ 
in  the  SOU’  and  CDRL  and  accepted  or  reiected  bv  the  PO  on  the  basis  of  com¬ 
pliance  with  those  documents.  Durinc  full-scale  development,  the  system 
specification  is  normally  placed  on  contract,  together  with  item-level 
specifications  and  SOU’  requirements  for  contractor  services  in  such  areas  as 
configuration  management,  interface  control,  system  installation/ integration , 
and  support  of  system  DT5E.  Again,  however:  while  contractors  are  now 
fullv  responsible  for  meeting  requirements  of  item-level  specifications,  the 
system  specification  continues  to  function  primarily  as  a  reference  source 
of  criteria  against  which  to  judge  the  acceptability  of  their  seri-ices-- 
not  as  a  direct  definition  of  characteristics  to  be  achieved  by  their 
deliverable  products. 
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It  was  mentioned  earlier  that  the  principles  upon  which  the  established 
structure  and  roles  of  specifications  are  based  were  derived  in  the  context  of 
svster.  acauisition  manajjement  policies  and  circumstances  which  existed  in  the 
earh-  19(i0s.  Some  of  the  problems  encountered  in  recent  years  can  be  traced  to 
changes  in  the  latter  wliich  have  not  been  accompanied  b>'  corresponding  revisions 
or  clarifications  of  the  principles  and  their  anplicability.  .Among  the  man)’  and 
varied  change s/t rends ,  two  are  noted  below  which  hav'^e  been  associated  prominent¬ 
ly  with  questions  about  functions  of  the  system  specification. 

I’O  Manpower.  It  is  an  in-built  assuirmtion  of  established  procedures  that 
the  PO  will  have  trained  and  experienced  personnel,  in  adequate  numbers  over  the 
range  of  significant  technical  and  support  management  disciplines,  to  "stay  on 
top"  of  a  system  program  throughout  its  duration.  However,  the  numbers  of 
trained  civilian  and  military  personnel  available  (and  authorized)  for  assign¬ 
ment  to  I’O  positions  have  decreased  markedly  over  the  years.  Kith  limited 
resources,  pressures  have  increased  to  shift  a  greater  portion  of  the  total  bur¬ 
den  to  contractors.  POs  at  ESP  have  in  fact  taken  measures  along  that  line,  in 
two  forms;  fal  of  acquiring  more  direct  support  to  the  PO  from  system  engineer¬ 
ing  contractors;  and  (b)  making  more  use  of  the  system  specification  instead 
of  allocated  baseline  specifications  as  the  primar)'  technical  requirements 
instrument  to  govern  full-scale  development.  Although  devices  of  necessity 
rather  than  choice,  both  of  those  have  been  reported  to  help  in  alleviating 
the  pressure.  As  indicated  in  the  preceding  discussion  of  system  specification 
functions  (5.1),  the  latter  represents  a  relatively  uncharted  approach  in  the 
light  of  established  principles  and  practice;  and  its  use  is  necessarily 
limited  to  something  less  than  the  total  system.  However,  additional  reasons 
which  suggest  that  it  should  perhaps  be  further  explored  are  discussed 
below. 

r.xi  sting  Items.  The  use  of  existing  commercial  and  Government  -  inventor)- 
Items  has  shown  a  steady  increase,  as  a  result  of  both  current  policv  and 
increased  availability  of  general-purpose  components,  to  the  point  that  thev 


noK  often  constitute  major  portions  of  a  total  electronic  svstem.  lio\vc\-er, 

Khiie  the  specification  structure  as  such  has  always  included  provision^-  fcr 

those,  most  of  the  substantive  guidance  for  managing  SN’stem  contracts  applies  ! 

to  items  of  new  development.  The  differences  in  indicated  faml  practicabl*' 

management  procedures  are  sufficientlv  extensive  that  care  has  been  taken  in 

some  programs  to  avoid  designating  the  commercial  elements  as  "configurat ioi, 

items”,  largelv  for  the  reasons  that:  their  commercial  spi  'ifications  are 

t>'pically  not  adequate  or  usable  for  configuration  control  at  either  the 

allocated  or  product  baseline  levels,  due  to  obstacles  posed  bv  considerations 

of  ownership  and  data  rights  as  well  as  content;  and  standard  procedures  for 

managing  technical  design  reviews,  qualification  testing,  and  configuration 

audits  are  not  applicable. 

TIk'  fact  that  T>'pe  P  specifications  arc  nor  written  for  commercial  items 
implies  that  special  attention  must  be  given  in  the  system  specification- -i .e. 
in  the  initial  issue--t.o  maintainability  and  related  support  requirements  to 
govern  the  selection  anu  acceptability  of  those  items.  ITie  nature  of  sue;, 
requirements  must  be  carefully  tailored  to  operational  and  support  concents  for 
each  svstem  with  respect  to  relevant  factors  of  geographic  location f s') ,  deplov- 
ment ,  and  environment . 

5.2.1  Illustrative  Problem  Case 

i-igure  3-4  contains  a  diagram  based  on  the  arrangement  of  principal  equip¬ 
ment  items  proposed  by  one  contractor  to  meet  the  requirements  of  a  s>’stem 
segr.ient  specification.  In  this  sample,  individual  items  identified  within  each 
of  the  four  sets  labeled  "functional  groups"  are  all  commercial,  including  two 
cr  three  requiring  some  degree  of  modification  for  this  intended  use.  Comouter 
programs  fnot  shown)  are  associated  with  each  of  the  functional  groups, 
consisting  of  both  operational  and  siq">port  items.  In  the  segment  as  a  whole, 
the  only  major  items  of  new  development  are  the  operational  CPCls. 

Referring  to  the  model  process  described  for  the  validation  phase  in  2.5 
above,  this  diagram  illustrates  a  situation  which  is  likelv  to  exist  at  about 
the  time  of  SRK,  after  the  contractor  has  analyzed  segment -level  requirements, 
allocated  those  to  functional  areas,  and  identified  principal  items  of  hardware 

hi 

! 

I 

i 


SI’Ar  r  (FNtfl)  SVSKfl  ■'.KlMttir 


ri^nro  :^-4.  Sninpio  ArninKeniciit  of  Miijor  r.»inipincnt  Items  in  a  System  Segment. 


I 


and  software  within  each  functional  area.  The  preponderance  of  commercial  items 
is  clearly  in  line  with  objectives  expressed  in  the  SOIV;  and  it  does  have  the 
basic  advantage  that  significant  factors  of  performance  and  cost  are  relativelv 
"proven"  as  compared  with  items  of  new  development.  At  the  same  time,  viewed 
in  the  light  of  accepted  acquisition  management  practices,  the  situation  poses 
to  the  PC  certain  novel  questions  and  problems  of  its  own: 

•  If  those  items  are  to  be  listed  in  the  expanded  system  specification 
and  their  commercial  "specifications”  accepted  and  approved,  the  PO 
must  perform  the  considerable  task  of  verifA'ing  indenendently  the  item 
selections,  performance  potentials,  and  interface  compatibilities  before 
incorporating  them  into  the  full-scale  development  contract. 

•  The  individual  items  shovn  in  this  diagram -- comput ers ,  consoles/dis- 
nlays,  and  related  equipment- -are  in  fact  properlv  identified  as 
"configuration  items",  to  the  degree  that  basic  criteria  for  Cl  identi¬ 
fication  and  selection  apply  at  all  to  this  total  segment  configuration. 
The  significant  consideration  is  that  each  is  a  level  of  assemblv 
separately  manufactured  and  documented  as  such,  and  in  many  cases  b>' 
separate  original  suppliers/contractors. 

•  Nevertheless,  there  will  be  little  or  no  eauipment  development  for  the 
PO  to  monitor  and  manage,  during  full-scale  development,  at  the  normal 
configuration  item  level.  Notably,  there  will  be  no  technical  design 
reviews  or  qualification  test  programs  for  the  commercial  items  as  a 
basis  for  their  audit  and  acceptance. 

•  Klien  contractors  are  responsible  for  CIs  of  new  development,  they  share 
a  portion  of  the  total  program  risk.  But  one  net  result  of  this  case, 
carried  to  its  logical  conclusion,  is  that  essentially  all  of  the  risk 
fi.e.,  for  system  equipment)  is  shifted  to  the  PO,  since  new  develop¬ 
ment  is  now  limited  to  complex  assemblies  above  the  level  of  CIs. 
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3.2.2  Proposed  Solution.*; 

The  situation  described  above  has  existed  in  several  procrams,  although  with 
a  number  of  variations  in  relevant  circumstances.  .4s  indicated  earlier,  ready¬ 
made  solutions  are  not  prescribed  in  the  current  standards;  and  this  guidebook 
does  not  have  a  simple  solution  to  recommend.  A  PC  faced  with  those  problems  is 
largelv  "on  its  own" --although,  to  avoid  problems  that  could  be  even  worse,  any 
novel  approach  must  take  full  account  of  basic  principles  which  the  established 
standards  and  oractice  do  reflect.  Some  considerations  are  summarized  below 
relating  to  each  of  three  approaches  that  have  been  tried  or  proposed  in  recent 
programs.  At  this  point  in  time,  all  of  these  need  further  study  to  clarify 
their  potentials  and  limitations  for  general  use. 

Two  of  the  three  solutions  referred  to  were  proposed  in  the  program  on 
which  the  diagram  shown  in  Figure  3-4  is  based.  The  other  fthe  first  discus.sed 
below)  has  been  implemented  in  other  programs. 

a.  One  PO  has  adopted  the  approach  of  using  the  system  specification  as  the 
sole  contracting  instrument  to  govern  development  of  all  system  hardware 
and  software.  Although  subject  to  limitations  discussed  previously,  there 
are  indications  that  this  device  can  be  made  to  work  in  some  cases.  The 
cases  knora  so  far  are  ones  in  which  the  system  happens  to  be  atypical ,  in 
that  it  does  consist  principally  of  one  large  prime  equipment  item  (a  "one- 
of-a-kind"  surveillance  radar].  The  purpose,  and  reported  real  result,  is 
to  reduc-'  demands  on  PO  manpower  by  placing  full  responsibility  onto  the 
system  contractor  for  all  management  at  the  Cl  level  during  full-scale 
development.  This  means  that  the  .*’0  has  correspondingly  less  control  at 
that  level  while  the  development  is  in  progress.  Implications  which  this 
PO  has  recognized  and  accepted  include  the  following: 

•  The  contract  specifies  that  normal  Cl-level  requirements  (for  develop¬ 
mental  Items]  are  to  be  observed,  in  a  normal  phasing  sequence,  in  such 
areas  as  development  specifications,  technical  design  reviews,  qualifi¬ 
cation  test  programs,  and  product  spec i ficat ions- -but ,  wholly  managed 
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and  controlled  b>’  the  prime  contractor  from  the  time  of  contract  award, 
through  successful  completion  of  system  DTSE.  The  system  testinc  is 
also  managed/conducted  bv  the  contractor,  but  v.utnessed  and  approved/ 
accepted  by  the  PO  (as  the  qualification  testing  would  normall>-  be  for 
a  cn. 

•  .-Mthouc*'.  the  PO  mav  act  as  an  observer  at  intermediate  CT- level  event.' 
and  receive  information  copies  of  documents,  it  does  not  accent  or 
control  Cl -level  nroducts  until  system  DT5E  is  completed.  .At  that  end 
point  of  the  program,  the  PO  then  holds  a  physical  configuration  audit 
(PCA)  to  examine  and  accept  the  CIs,  their  specifications,  and  other 
documentation. 

•  Configuration  management  procedures  are  adjusted  accordingly.  Through¬ 
out  the  period  of  initial  acquisition,  the  PC's  configuration  control 
is  confined  to  the  functional  baseline  level .  The  prime  contractor  may 
report  to  the  PO  changes  to  CI/G’CI  specifications  which  he  has  base¬ 
lined  for  internal  control,  but  in  the  form  of  "record-only"  ECPs. 

h.  The  system  on  which  the  diagram  shown  in  Fi,gure  o-*!  is  based  was  substan¬ 
tially  larger  and  more  complex  than  the  case  just  described;  and  computer 
programs  were  a  more  oreminent  part  of  the  total  acquisition.  The  olan  to 
manage  computer  programs  as  individual  CPCIs,  in  accordance  with  normal 
practice,  was  not  in  question.  With  respect  to  equipment,  however,  the 
questions  and  problems  outlined  in  3.2.1  above  led  members  of  the  PO  to 
search  for  an  alternative  approach.  Of  two  alternatives  proposed,  the  one 
adopted  fin  some  haste)  was  later  reported  bv  participants  to  have  created 
more  oroblems  than  it  solved.  Tliat  concept  is  outlined  as  follows: 

•  Each  of  t.he  complete  assemblies  illustrated  as  a  "functional  group" 
in  figure  3-^  was  designated  as  a  prime  item  of  new  development. 
Equipment  CIs  identified  by  specific  numbers  and  nomenclature  in  the 
system  (segment!  specification  tree  and  Cl  list  were  confined  to  those 
prime  items. 
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•  The  sepnent  contractor  was  required  to  prepare  a  T\Tie  HI  specification 

for  each  of  the  functional  groups,  to  be  followed  later  hv  a  Clh 

(product  fabrication)  specification.  Hollov.in.c  acceptance,  the^■  wouic 
become  items  in  the  Air  Force  inventor'.-  at  that  level,  identified  as 
items  manufactured  bv  the  PC's  secment  contractor. 

•  Iic'vclopment  and  test  plans  for  full-scale  development  provided  for 
design  reviews,  qualification  testing,  and  configuration  audits  at  the 
functional  group  (prime  item)  level. 

.Some  of  the  problems  encountered  in  the  cour.se  of  implementing  that  plan 
re,sulted  from  difficulties  experienced  by  the  contractor  in  preparing  the 
spec i f lent ion.s ,  narticularlv  at  the  product  fabrication  level.  Guidelines 
for  handling  the  commercial  items  ('now  identified  as  commercial  comprmenzs  ' 
were  nc\'er  clcarlv  formulated;  and  they  proved  to  be  matters  of  disagree¬ 
ment  With  respect  to  a  range  of  questions  having  to  do  with  the  use  of 
commercial  documentation,  quality/foms  (and  even  availability.)  of  engi¬ 
neerin'.:  drawin.’s,  test  di.ata  iind  special  test  support  equipment  for  the 
cornaercial  components,  and  otiiers.  (.'>ne  sispiificant  factor  which  tended  to 
exacerbate  nroldems  was  the  fact  that  the  recaiirement  for  the  contractor  to 
assume  tiiose  resixuisibi  1  it  le'--  did  not  emerge  until  after  the  contract  had 
■Started,  luid  after  the  contractor  to  the  PC'  iiad  alreadv  negotiated  sub¬ 
contracts  anti  purchase  agreements  with  original  equipment  manufacturers. 

c.  The  alternative  which  was  proposed  but  discarded  in  favor  of  that  just 
..iescribet!  is  not  knoia:  tc.  have  been  implemented  in  an  actual  program. 
Howei-er,  there  .'ire  reasons  to  Del  leve  it  would  have  neen  a  better  course 
to  follow.  Tlie  concej't  derived  in  part  from  the  fact  that  a  validation 
piiase  hati  not  heen  conducteu;  and  there  wa<.  earlN-  ei'idence  that  the  si'stem 
sp'.-ci  ficat  ion- -which  consisted  of  jone  general  volume  and  separate  I’olumes 
’.'or  the  S'.’stem  segment - -iia.i  suftered  from  an  absence  of  both  fl  )  thorough 
s'stei:'  eni'ineeniu'  imah’sis  and  verification,  and.  (2,  specific  ex^iansions 
air:  refinements  b>-  tiie  successful  semicnt  contractors  to  reflect  tlieir 
intended  desieii  aoprciaches .  Based  primarilv  on  discreiianc ies  in  the 
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latter  area,  combined  with  the  considerationr  Jescribevi  in  '.r.]  above-,  thi^ 

jroposal  outlined  the  following  principal  steps: 

•  The  contractor's  first  task  is  to  expand  the  svsteiTi  seement  specifica¬ 
tion  to  define  functional  areas,  allocate  requirenents  to  those,  <xn  ’ 
verifv  consistence  with  the  segment  reouirements  as  a  whole,  'ntbin 
each  functional  area,  requirements  are  furtlier  allocated  to  conputer 
programs  and  equipment.  However,  while  the  CPCls  are  identified  speci¬ 
fically,  reouirements  allocated  to  equipment  are  .siiecified  for  the  groun 
of  equipment  elements  in  each  functional  area  as  a  vdiole. 

•  liouipment  items  comprising  each  functional  group  are  identified  at  tin.' 
time  by  generic  names  only.  Tlie  PC  neither  approves  their  selection 
nor  accepts  their  individual  (commercialj  specifications. 

•  Taking  into  account  the  fact  that  Tvqie  B  specifications  will  not  exist 
to  provide  further  detailed  performance/design/ interface  reouirements 
at  the  item  level,  the  definitions  of  requirements  provided  directlv 
the  svstem  segment  specification  itself  must  be  comnarable  in  scope  and 
level  to  the  content  of  a  Tr^pe  B1  specification  for  each  functional 
group  as  a  whole. 

•  Once  completed  and  approved  with  those  changes,  the  system  segment  speci¬ 
fication  is  then  placed  on  contract  to  govern  the  contractor's  develop¬ 
ment  of  those  functional  groups.  Development  and  test  Plans  are  prepared 
to  schedule  design  reviews,  testing,  and  configuration  audits  for  each 
functional  group.  .Acceptance  of  individual  equipment  items  will  occur 
when  bfAs  arc  completed  successfully  for  the  functional  groups.  T;ie 
system  segment  specification  is  then  updated  to  incorporate  specific 
identification  of  the  commercial  items.  .After  that  time.  Air  Force- 
management  ma%'  then  revert  to  the  item  level  for  purposes  of  logistic 
support  and  account ahi 1 i tv. 
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5 . ?  Program  Risks 


A  "program  risk"  is  a  factor  which  creates  a  likelihood  that  system  perfor¬ 
mance  or  sunportability  obiectives  ma''  not  be  achieved  within  the  acceptable 
range  of  projected  program  costs  and  schedules.  Since  it  is  characteristic  of 
system  programs  that  they  are  initiated  and  carried  out  to  develop  new  capabili¬ 
ties  which  take  advantage  of  the  latest  available  technolog>’,  the  risks  which 
tend  to  receive  most  visibility  and  attention  are  those  of  a  technical  nature. 
Following  a  number  of  experiences  in  ear]\'  system  programs  which  attempted  to 
incorriorate  scheduled  "teclinological  breakthroughs",*  it  has  long  been  a  policy 
within  the  DoD  not  to  permit  a  system  program  to  proceed  into  full-scale  engi¬ 
neering  development  until  assurance  e^^ists  that  technical  risks  have  been 
minimized- -meaning ,  specifically,  that  subsequent  effort  must  be  a  matter  of 
straightforward  engineering  design  and  development  without  significant  depen¬ 
dence  on  further  invention  or  scientific  advancements.  Current  policies  also 
emphasize  earlv  identification  and  reduction  of  related  risks  associated  with 
the  svstem  operability  and  performance  in  its  intended  militan-  environment. 

Thus,  in  the  context  of  problems  encountered  during  full-scale  development 
and  later  phases  of  system  programs  with  embedded  computer  resources  in  recent 
\X'ars,  there  has  been  a  widespread  tendency  to  assume  that  the  computer  re- 
soLirce.s ,  especially  computer  programs,  constitute  areas  of  high  technical  risk. 
Hence,  steps  to  improve  the  software  base  of  technology  and  abilities  of  Program. 
Offices  to  monitor  and  evaluate  the  technical  aspects  of  software  dev'^elopment 
have  been  prominent  among  lines  of  activity  taken  to  alleviate  the  problems. 
Tnose  efforts  are  clearlv  needed  and  appropriate,  to  a  degree.  However,  the 
lisks  (known  or  uniaiown  at  the  timel  which  have  actually  materialized  into 
prograii,  problems  or  failures  indicate  that  increased  attention  is  also  needed 
tc  a  number  of  related,  other  factors  in  the  system  acquisition  Program  as  a 
whole. 


*NotabIc  examples  durinj’  the  IP.SOs  were  a  nuclear -powered  aircraft  ('.Svstem  llSAl 
and  the  outer-atmosphere  v^ehicle,  [hTiasoar. 
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Considering  the  corrolexity  of  large  system  programs,  failures  can  result 
from  deficiencies  in  any  one  or  more  of  many  areas.  To  be  successful,  the 
Program  Office  must  take  steps  to  assure  that  adequate  attention  is  oaid  to 
minimizing  risks  across  the  whole  spectrum  of  potential  pitfalls.  That  is  to 
say,  concentration  on  eliminating  anv  one  risk  factor,  however  significant,  is 
"necessar)',  but  not  necessarily  sufficient".  Howev’er,  the  following  paracranhs 
discuss  a  few  risk  factors  associated  with  the  system  specification  whicli 
clearly  merit  far  more  concentrated  attention  than  thev  have  tiqiicallv  been 
given. 

Based  on  many  surveys,  there  is  a  wealth  of  evidence  that  the  most  pen^asive 
single,  technical  source  of  difficulties  in  system  programs  is  a  matter  of  defi¬ 
ciencies  in  the  amount  and  quality  of  systerr,  engineering  effort  applied  during 
early  phases  to  develop,  document,  and  verify  adequate  definitions  of  require¬ 
ments.  This  deficiency  has  been  recognized  as  being  a  chronic  characteristic  of 
system  programs  in  general,  for  decades.  Awareness  of  its  effects  on  problems 
with  embedded  software  are  evidenced  in  such  comments  ^b^’  system/ software  con¬ 
tractors!  as  the  following:* 

"...initial  requirements  were  not  critically  analyzed  and  verified  througli 
a  formal  program  of  advanced  development  or  system  definition." 

"...lack  of  thorough  analysis  and  validation  of  requirements." 

"...many  technical,  cost,  and  schedule  problems  can  be  traced  to  inade- 
auatelv  defined  requirements." 

"Often  the  difference  between  success  or  failure  of  a  large  software 
project  lies  in  the  consistency  ajid  completeness  with  which  the  svstem 
reouirements  have  been  specified..." 

"Much  more  effort  and  money  should  be  expended  on  the  preparation  of  good 
development  specifications...  The  Government  should  be  an  active  parti - 
cip,int  in  the  technical  effort  loading  to  these  specifications." 


*Sclected  quotations  drawn  from,  the  UoD  Weapon  Systems  .Software  'lanagement 
Study  fref .  1“  ) . 
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Dus  k(.'\  I'actor  accounts  ioi'  tlio  emphasis  placed  ahovc,  in  Vlie  discu' 
sion  of  system  specification  development  fSection  2),  on  thorough  analysis  of 
system  requirements  during  the  conceptual  phase,  and  on  emplo>Tnent  of  the  vali¬ 
dation  phase  for  the  primarc’  purpose  of  completing/expanding  the  definitions  of 
system  and  software  requirements.  Those  objectives  are  consistent  with  current 
Air  Force/DoD  policies,  although  it  must  be  recognized  that  there  has  been  a 
dearth  of  guidance  or  support  for  their  implementation  in  the  manner  described, 
specifically  for  electronic  systems/computer  resources. 

One  possible  source  of  confusion  lies  in  the  label  "validation  phase"  it¬ 
self,  which  tends  to  highlight  the  importance  of  such  activites  as  prototype 
demonstration  and  hardware  proofing.  Those  activites  are  indeed  emphasized 
within  the  DoD  for  major  defense  systems  in  general.  However,  it  is  also  clear 
that  that  emphasis  is  based  primarily  on  reference  to  systems  in  which  the 
focal  developmental  efforts  and  technical  risks  are  associated  with  major  new 
prime  items  of  military  equipment -- such  as  supersonic  bombers,  cruise  missiles, 
ballistic/antib.allistic  missiles,  nuclear  submarines,  or  tactical  aircraft.  The 
early  demonstration  principle  is  still  only  the  "means  to  an  end";  its  function 
is  to  support  the  mainline  objective  of  minimizing  program  risks  before  embark¬ 
ing  on  a  full-scale  development. 

Tlius,  in  tailoring  his  program  according  to  its  needs,  it  is  incumbent  on 
the  electronic  system  Program  Manager  to  examine  the  applicability  of  those 
concepts  in  the  light  of  their  significance  to  his  actual  circumstances,  bbile 
there  may  be  exceptions,  the  overwhelming  weight  of  electronic  systems  experi¬ 
ence  dictates  that  in  most  cases  he  should — indeed,  must — conduct  a  validation 
phase,  hut  will  rarclu  have  good  reason  to  require  prototype  demonstration/ 
hardware  proofing  tasks  as  significant  parts  of  that  effort.  .A  few  of  the 
relev'ant  considerations  are  summarized  below. 

a.  The  validation  phase  task  of  contractors  to  analyze  and  complete  the  system 
specification  represents  an  important  sten  in  assuring  that  the  specifica¬ 
tion  is  a  sound  instrument.  Even  when  it  mav  have  had  the  benefit  of  good 
system  engineering  study  and  verification  during  the  conceptual  phase. 
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there  is  still  the  need  to  assure  that  its  requirements  are  compatible  vith 
design  approaches  proposed  as  being  knoun  and  feasible  b\  t!ie  implementing 
contractor (s) . 

b.  Equally  important  in  promoting  the  PO's  confidence  that  contractors  reallv 
understand  the  requirements  and  their  implications  are  the  results  of  asso¬ 
ciated  implementing  tasks  during  the  validation  phase--of  identif-inp  items 
of  hardware  and  software,  developing  item-level  performance  specifications, 
analyzing  development  and  support  requirements,  and  preparing  comprehensive 
plans  for  full-scale  development.  If  there  is  any  single  factor  that  car  be 
pointed  to  as  having  the  highest  priority  for  embedded  software,  snecific;.  1 1 ' . 
it  is  clearly  in  the  area  of  improved  develonment  specification*^  for  opera 
tional  computer  programs. 

c.  Viaior  new  prime  items  of  equipment  are  not  normallv  developed  as  part  of  an 
electronic  system  program.  Predominantly,  the  hardware  portions  of  the 
system  consist  of  digital 'computing  equipment,  communications  devices,  and 
consoles,  hliile  some  of  the  elements  may  be  newly -developed  for  the  eii'en 
program,  they  are  largely  commercial  off-the-shelf  or  consist  of  commercial 
components  arranged  in  a  tailored  configuration.  The  risks,  in  practice, 
tend  to  be  matters  of  proper  selection  and  assembly  of  those  items  such 
that  the  equipment  configuration  as  a  whole,  once  installed,  will  meet 
system  requirements  with  respect  to  types  of  data  processing,  speeds, 
capacities,  reliability,  and  supportability . 

d.  The  prominent  items  of  new  development  for  most  electronic  svstems  tend  to 
be  operational  (mission,  or  applications!  computer  programs.  There  are 
some  known  examples  in  which  certain  requirements  stated  in  the  svste^- 
specification  have  raised  questions  of  technical  feasibility--and/or  tech¬ 
nical  competence  of  the  contractor --that  might  conccivablv  be  resolief;  cr 
clarified  by  means  of  "software  proofing"  or  earli’  demonstration.  How¬ 
ever: 

ril  'lore  often  than  not,  those  questions  should  normal  1\-  have  been  exam¬ 
ined  and  re<=olved  before  romiileting  the  initial  s\  vtri:i  snee i  f icat  ion . 
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Most  of  the  knoviTi  instances  (e.g.,  questionably-strinpent  require¬ 
ments  for  data  security)  are  ones  which  imply  long-term  study,  and  are 
by  no  means  confined  to  software. 

"21  Unless  there  happens  to  be  a  specific  objective  which  is  known  to  be 
exceptionally  important,  requirements  for  early  demonstration  as  part 
of  the  validation  phase  should  be  avoided.  In  the  competitive  environ¬ 
ment,  contractors  are  likely  to  channel  their  principal  and  best 
resources  into  that  activity;  and  the  other,  typically  higher  priority 
objectives  of  comprehensive  requirements  and  program  definition  will 
suffer  accordingly. 

(31  Experience  clearly  indicates  that  the  PC's  most  urgent  source  of  con¬ 
cern,  normallv,  is  whether  the  contractor  will  be  able  to  deliver  a 
total,  integrated  collection  of  the  system  software,  on  time  and  within 
estimated  costs,  which  really  meets  the  full  range  of  system  operational 
and  support  requirements.  No  case  has  yet  been  reported  of  a  system 
program  failure  caused  by  limitations  in  software  state-of-the-art  as 
such.  The  plethora  of  actual  problems  encountered -- i . e . ,  the  real-life 
risks  which  have  so  often  been  taken  and  lost --are  matters  of  inade¬ 
quate  requirements  definition,  planning,  and  management. 
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AI'PENDIX  A.  SYSTEM  SPECIFICATION  PRF,PAR'\TIO\ 


^foSL  of  the  content  of  this  appendix  is  dram  froin  a  system  specification 
preparation  guide  which  was  developed  at  AFSC’s  Space  Division  fSP) .  nie 
material  is  used  herein  with  the  permission  of  its  author,  Ih'.  Ernest  hade  of 
The  Aerospace  Corporation,  to  whom  this  author  is  also  indebted  for  consultation 
in  adapting  it  for  this  use.  hOiile  that  guide  emphasizes  requirements  which  arc- 
important  in  space  systems,  it  also  contains  information  which  is  both  generally 
useful  and  potentially  helpful  in  tailoring  the  MII.-STD-4D0  instructions  to 
other  classes  of  systems. 

The  principal  sources  of  general  requirements  for  preparing  a  system  speci¬ 
fication  are  Appendix  1  of  MIL-STD-490  and  Appendix  III  of  MIL-STD-483  GJS.-iF'i . 
The  instructions  contained  in  those  sources  set  forth  minimum  requirements  which 
are  isxitten  at  a  veip-  general  level  tc  cover  all  classes  of  militan-  systems, 
and  to  sen^e  the  generally-useful  purpose  of  enforcing  a  base  of  standard 
practice.  However,  it  has  been  the  common  experience  that  a  substantial  amount 
of  additional  direction  and  guidance  is  needed  to  support  their  effective  use  in 
any  given  case. 

Basic  sections  of  this  guidebook  have  emphasized  the  fundamental  problem  of 
developing  and  verifying  an  adequate  foundation  of  requirements  data  to  provide 
the  essential  technical  content  of  a  good  system  specification.  Beyond  that, 
however,  the  process  of  translating  the  input  information  into  statements  of 
requirements  which  are  consistent  with  sound  specification  practices  is  a  sig¬ 
nificant  task  in  itself,  particularly  when  combined  with  ts-pical  needs  to 
adjust  the  specification  format  and  emphasis  to  a  given  class  of  svstems. 

A  committee  which  was  formed  to  investigate  problems  encountered  with  one 
system  specification  at  ESD  recommended  recently  that  a  new  pamphlet  be  devel¬ 
oped  as  a  .guide  to  the  specification  preparation  for  electronic  svstems.  hhile 
that  topic  is  clearly  w'ithin  the  scope  of  subjects  which  deserx'e  coverage  in 
this  guidebook,  it  is  recognized  that  the  task  as  a  whole  demands  longer  time 
and  a  broader  base  of  resources  than  have  been  allocated  to  preparation  of  this 


initial  issue.  Thus,  the  material  presented  belov  is  limited  to  available  and 
relevant  information  which  may  prove  useful  as  a  starting  point  for  such  a 
longer-term  effort. 

Organication  and  Content 

To  avoid  the  use  of  a  dual  numbering  system,  paragraphs  in  the  remainder  of 
this  appendix  are  identified  by  the  section/paragraph  numbers  and  titles  speci¬ 
fied  for  the  system  specification  in  MIL-STD-490.  For  reference,  an  outline  of 
that  specification  structure  as  a  whole  is  reproduced  in  Figure  .A-1.  fNote; 
the  coverage  provided  herein  extends  only  through  Section  5.) 

Guidance  material  presented  in  the  following  pages  is  organized  around 
successive,  relatively  short  groups  of  related  specification  paragraphs.  The 
material  associated  with  each  group  consists  of  information  derived  from  three 
sources:  O'  content  of  the  basic  SD  guide;  (b)  content  of  a  "model  specifica¬ 
tion”  which  was  printed  originally  as  an  appendix  to  the  SD  guide;  and  (c) 
comments  by  the  author  of  this  S.AM  guidebook  on  significance  of  selected  topics 
to  electronic  s\’stems.  For  ease  of  ready  identification  by  readers,  those 
three  kind.s  of  content  are  presented  in  different  type  style  or  format,  as 
illustrated  in  the  explanations  provided  below; 


Paragraph  x.x,  Basic  SD  Guidebook.  This  element,  taken  from  Mr.  Wade's  guide¬ 
book,  incorporates  Instructions  extracted  from  MIL-STD-490  for  the  identified 
section  or  paragraph,  explains  the  instructions,  and  contains  additional  notes 
to  assist  specification  writers  to  interpret  their  applicability. 


x.x  Model  Specification.  This  element  is  also  drawn  from  the  SD  guide. 
It  provides  direct  illustrations  of  the  MIL-STD-A90  format  and  "boiler¬ 
plate"  requirements  statements  for  each  section/paragraph,  to  which  each 
specification  writer  may  then  add  statements  peculiar  to  his  own  system 
program. 


ELECTROKIC  SYSTEMS  -  COMMENT.  This  element  does  not  always  appear.  Hhen  it 
does,  it  consists  of  comments  on  selected  portions  of  the  system  specification 
whicli  are  judged  to  be  of  particular  interest  or  imjiort ajice  to  computer 
resources  aspects  of  electronic  .systems. 
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SYSTEM  SPECIFICATION 
CONTENT  OUTLINE 
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3.1.6  Government  Furnished  Property  List 
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licure  A-1.  -  CtmteiU  UutJiiu-  fur  the  Svstem  Spec i f i cu I i on 


Section  1,  SCOPS.  As  shown  in  the  Model  Specification,  the  first  section, 
SCOPE,  starts  on  page  1  of  the  specification. 


Subsection  1.1,  Purpose.  The  material  to  be  included  in  this  subsection  should 
consist  of  a  clear,  concise  abstract  in  one  paragraph  of  the  scope  and  purpose 
of  the  coverage  of  the  specification.  If  desired,  a  concise  statement  of  the 
intended  application  of  the  specification  may  also  be  included. 

Subsection  1.2,  Classifications.  This  subsection  is  included  in  the  event  that 
different  classifications  of  the  space  system  are  to  be  covered  by  the  specifi¬ 
cation.  Because  various  classifications  of  space  vehicles  or  other  items  that 
might  be  identified  in  lower  tier  specifications  are  usually  all  part  of  the 
same  system,  the  "Not  applicable"  entry  shown  in  the  Model  Specification  is 
usaually  correct. 

Note  that  there  are  minor  differences  in  1.1  and  1.2  between  Appendix  I 
of  MIL-STD-'iSO  and  the  general  requirements  for  Section  1  given  in  the 
body  of  MIL-STD-490.  The  guidebook  presents  a  reasonable  resolution 
of  the  discrepancies. 


1 .  SCOPE 

1.1  Purpose.  This  specification  sets  forth  the  requirements  for  the 
design,  development,  manufacture,  test,  and  Quality  assurance  of  the  (in¬ 
sert  nomenclature)  space  system  hereinafter  referred  to  as  the  system.  The 
requirements  covered  bv  this  specification  are  applicable  to  the  (insert 
nomenclature)  svstem  which  is  a  major  element  of  the  (insert  program  iden¬ 
tification).  TJtese  requirements  shall  be  the  basis  for  the  preparation  of 
more  detailed  requirements  to  be  included  in: 

a.  subsequent  revisions  of  the  system  specification,  and  in  related 
system  documents,  such  as  interface  control  documents  (ICDs); 

b.  specifications  for  the  system  segments  and  for  configuration  items 
(CIs)  at  lower  levels  of  assembly. 

3-2  Cl assif ications .  (Not  applicable). 


Section  2,  APPLICABLE  DOCUMENTS.  As  shown  in  Section  2  of  the  Model  Specifica¬ 
tion,  Governmental  documents  are  listed  in  subsection  2.1  in  numerical  order 
under  each  of  the  subheadings  shown.  Non-governmental  documents  are  listed  in 
subsection  2.2.  Non-governmental  documents  are  those  not  issued  bv  an'’  govern¬ 
mental  organization  such  as  documents  issued  bv  technical  associations,  tech¬ 
nical  societies,  commercial  organizations,  and  contractors. 

The  words,  subheadings,  and  format  should  be  followed  with  the  understanding 
that  subheadings  will  be  omitted  if  thev  do  not  contain  applicable  documents. 

A  parenthetical  source  statement  should  follow  each  group  of  related 


publication*;  indicatins  the  address  of  the  source  of  the  document  so  that 
copies  tnav  be  obtained  directlv  from  the  source. 

All  and  only  these  documents  identified  and  referred  to  in  Sections  3,  4,  and 
f  of  the  specification,  or  in  mandatory  compliance  appendices,  are  listed  in 
Section  2  of  the  specification.  It  must  be  understood  that  the  whole  of 
referenced  documents  is  not  made  applicable  by  their  inclusion  in  Section  2. 

The  e.xtent  of  appllcabi 1 itv  is  only  that  which  is  clearlv  defined,  and  speci¬ 
fically  indicated,  at  the  olace  it  is  referenced.  The  documents  listed  in 
Section  2  of  the  Model  Specification  are  those  that  are  alreadv  referenced  in 
the  boilerplate  reouirements  of  the  Model  Specification.  As  other  requirements 
are  added  during  the  preparation  of  a  particular  system  specification,  other 
oocuments  may  be  referenced  and  they  would  also  be  added  in  Section  2.  Govern¬ 
ment  regulatory  documents,  such  as  directives,  regulations,  manuals,  pamphlets, 
and  policies  are  not  usually  cited  for  compliance.  These  documents  are 
generally  intended  for  internal  use  bv  governmental  organizations  only  and  are 
not  intended  for  contractor  use.  Contractors'  internal  specifications  or 
documents  are  not  usuailv  cited  for  compliance  because  they  are  tvpicallv  for 
internal  contractor  use  and  are  not  readily  available  to  reviewing  organiza¬ 
tions  nor  sre  thev  so  general  as  to  be  directlv  applicable  or  transferable  to 
a  different  contractor. 

Note  that  a  specific  issue,  revision  letter,  and  the  date  of  issue  is  given  for 
each  of  the  referenced  documents.  The  revision  letters,  amendments,  notices, 
and  effective  dates  shown  for  the  documents  listed  in  the  Model  Specification 
may  not  be  curront;  they  will  require  updating  to  the  date  of  issue  for  each 
specification.  Note  that  amendments  to  military  specifications  supersede 
earlier  amendments  so  only  the  most  recent  would  be  listed.  Notices,  however, 
are  cumulative  and  only  those  notices  to  be  made  applicable  would  be  listed. 

If  all  "m"  notices  were  applicable,  they  would  be  listed  as  notices  "1" 
through  "m"  with  the  date  being  that  for  notice  "m" .  Note  that  the  preferred 
method  of  stating  the  date  of  issue  for  each  document  is  as  the  year,  month, 
and  day.  The  year  would  be  given  in  two  digits,  the  month  in  three  capital 
letters,  and  the  day  in  two  digits.  If  a  different  date  format  is  used,  it 
should  be  used  consistently  for  all  of  the  documents  listed.  As  the  acquisition 
process  moves  forward,  many  of  the  specific  documents  referenced  may  be  amended, 
revised,  or  superseded.  Just  because  a  referenced  document  may  have  been 
updated  does  not  mean  that  the  revision  should  be  referenced.  The  actual 
updating  of  the  date  of  issue  for  each  of  the  references  in  the  specification, 
however,  must  be  considered  and  controlled  bv  the  program  offices  in  the  same 
manner  as  any  other  changes  in  the  .specification. 

Note  that  the  preparation  of  this  section  deviates  in  some  areas  from  the 
requirements  in  MIL-STD-483  and  MIL-STD-490.  For  example,  MIL-STD-490 
stares  that  Government  regulations  and  acts  of  Congress  should  be  refer¬ 
enced  in  specifications  whereas  those  "internal"  document  references  are 
nc  longer  acceptaole. 


2.  applicable  DOCmiENTS 

2.1  Governmental  documents.  The  following  documents  of  the  exact 
issue  shown  form  a  part  of  this  specif ication  to  the  extent  specified 
herein . 

SPECIFICATIONS: 

Federal 

Military 

DOD-E-8983C  Electronic  Equipment,  Aerospace,  Extended  Space 
77  DEC  29  Environment,  General  Specification  for 

MIL-M-38310B  Mass  Properties  Control  Requirements  for  Missile 
7A  JUN  15  and  Space  Vehicles 

DOD-W-8357A  Wiring  Harness,  Space  Vehicle,  Design  and  Testing, 

77  DEC  22  General  Specification  for 

MIL-S-83576  Solar  Cell  Arrays,  Space  Vehicle,  Design  and 
74  NOV  01  Testing,  General  Specification  for 

DOD-A-83577A  Assemblies,  Moving  Mechanical,  for  Space  Vehicles, 

78  MAR  15  General  Specification  for 

DOD-E-83578  Explosive  Ordnance  for  Space  Vehicles,  General 

79  OCT  01  Specification  for 


Program  Specifications 


(TBS) 


Other  Government  Activity 
STANDARDS: 


Federa  1 


Military 

MIL-STD-1472B  Human  Engineering  Design  Criteria  for  Military 
74  DEC  31  Systems,  Equipment  and  Facilities 

Notice  1 
76  MAY  10 


Ml  I.-STIi-  1  522  St.md.ird  General  Keouirements  for  Safe  Design  and 
72  Jl'l,  01  Oneration  of  Pressurized  Missile  and  Space  System."' 
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DRAI-’TN’ns :  CWhere  detailed  drawings  referred  to  in  a  specification  are 

listed  on  an  assemblv  drawing,  it  is  onJv  necessary  to  list 
the  assemblv  drawing.) 

OTHER  PUBLICATIONS: 

Manuals 

Regulations 

Handbooks 

MIL-HDBK-SC  Metallic,  Materials  and  Elements  for  Aerospace 
Vehicle  Structures 

MIL-HIHK- 17A  Plastics  for  Flight  Vehicles  -  Part  2,  Transparent 
Glazing  Materials 

Bulletins 


(Conies  of  specifications,  standards,  drawings,  and  publications  required 
by  suppliers  in  connection  with  specified  procurement  functions  should  he 
obtained  from  the  contracting  office  or  as  directed  bv  the  contracting 
officer . ) 

2.2  Non-governmental  documents.  The  following  documents  of  the  exact 
issue  shown  form  a  part  of  this  specification  to  the  extent  specified 
herein . 

SPECIFICATIONS; 

STANDARDS: 

DRAWINGS: 

OTHER  PUBLICATIONS: 

(Technical  societv  and  technical  association  specifications  and  standards 
I  are  generally  available  for  reference  from  librairies.  They  are  also  dis- 
'  tributed  among  technical  groups  and  using  Federal  agencies.  The  contract- 
!  ing  officer  should  be  contacted  regarding  the  availabilit'-  of  any  refer- 
I  enced  document  not  readilv  available  from  other  sources.) 


Section  3,  REQUIREMENTS.  As  shown  in  Section  3  of  the  Model  Specification,  the 
reauircments  should  be  stated  in  terms  of  performance,  reliability,  design 
constraints,  functional  interfaces,  etc.  that  are  necessar\'  to  assure  a 
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rr;urit'ai  and  reasonable  deveic'nment  effort.  The  recuirenents  shoula  ;;le.ir;'. 
describe  I'ne  space  svsceit  and  should  include  any  unique  space  requirement.s  sue':. 

.iS  for  raanufacturiny  process  control  of  critical  items.  Note  that  t'ne  ma-cr 
elements  of  the  space  svseem  mav  include  ground  equipment  as  well  as  the  snace 
eauinment .  Reouirements  that  are  onlv  anolicatle  to  some  of  the  elements  should 
not  he  stated  in  wavs  that  would  make  those  requirements  applicable  to  the 
entire  svstem.  Functional  statements  of  the  reouirements  should  predominate  ir. 
svstem  specifications  with  fabrication  cer.iils  specified  orlv  to  assure  matching 
interfaces  with  existing  elements.  As  the  accuisition  progresses  the  TESs  .and 
Tubs  would  be  determined  and  those  requirements  would  be  incorporated  in  tne 
specification  .and,  if  appropriate,  in  lower  tier  s'nec  if  icat  ions .  The  maicr 
c'fcri  in  the  initi.al  pb.ases  of  a  nrograir  is  in  the  allocation  of  the  require¬ 
ments  to  lower  leveis  of  assetn'olv  and  the  preparation  of  specifications  for  the 
svstetr.  segments  and  lower  tier  CIs. 

Kt’ferencine  militar\-,  federal,  and  DcD  .adopted  industr'-  .specif  icat  ions  and 
St  anCi.irci..;  is  the  approved  method  for  establishing  requirements  that  are  ade- 
cu.atei'.'  .set  forth  in  the  referenced  documents.  Before  referencing  anv  document, 
ue  sure  to  read  the  specif  ii.  issue  of  the  referenced  document  to  assure  the 

appl  icabil  i :  V  of  the  requi  reau'nts .  Tailt'rinu  riie  references  should  be  accom-  I 

plis'iied  to  limit  the  extent  of  apo]  icabil  i  tv  cf  t'ne  reouirements  such  as  illus¬ 
trated  in  the  following  examples: 

a.  "T'ne  design  of  electremic  components  .shall  be  in  accordance  with 

finD-R-Rhbd"  would  incorporate  onlv  the  design  requirements  of  D01>-E- 
f(ir  all  eU'Ctror.if  conpone:its  covered  by  the  spec  if  icat  lo  (both 
crcHind  .ind  spai  e  )  .  T'rie  qualitv  assurance  provisions  wc  ulc  nC't  be  made  ' 

.applica'tle  dv  such  a  reference. 

"T'ne  design  c>f  the  receiver  X  shall  be  in  accordance  wit'!.  fOD-E-E^Sl" 

Won  id  i  r.corpor.'it  e  onlv  the  de.sign  reouirements  of  DOD-F.-89fi3  for 
receiver  X,  'n.j'  no'  for  anv  other  possible  receivers  or  anplications 
ill  the  svsteir,  being  snecified. 

I 

■ctronic  components  for  sn.ice  vehicle  anplications  shall  be  in 
ordance  witi:  m;ikes  all  renuirements  (design  and  qualitv 

.•i.s.si:ran<e  1  in  apnlica'nle  to  the  electronic  comnonents  to  be 

u.‘a.'c:  in  ..p.a  i-  ven.icies  covered  nv  the  specification.  Renu irement. s  in 
pMfi-F-Hdg  ;  w.iuld  nt't  r.e  made  applicable  to  grt'und  components  or  to 
aircraft  comnonentv  jiv  suc'li  a  reference. 

a  g.dii-ra:  lull  .  pr  vT.ii.  ne.  ul  i.nr  ite:;.  spec  i  i  i  <'a  t  ;  on.s  external  to  the  svster 
.  ■  -.neoified  siuiuld  ii  't  he  referenced  except  to  identlfv  an  Interface. 

1.;.  '.Of  .'ippl  i  ca:.  1  e  requirements  should  be  extracted  and  incorporated  in 
'  ■  1  r  •  1  re  I  ■  . 

'  ■  '1"^’ !  i  u  i  t  i  on .  rtie  lulen:  of  'be  mater:...',  i;:.  iuded  in  this  su'psec- 

■  ’  ontier  p.ir.tgT  atc.s  i-  r  •  .  le.-ir';'  .let  me  tne  -voteiT'  riiat  is  neing 

'  :  'o.  As  will'  definition,  t'ne  ii.ient  i not  to  -tc.te  detailed,  "sr.nll"  I 

:'■■■'e:lt'  nut  t,  o  i:r;  dio..  ri’t-e  Inc  o'  •  er  ..p.:  f  lientif"  its  mahm  i 

'  .on. el’:  .  Its  tun  tio'i.i!  .ire.o  ,  .m  !  i ;  ■  ■.  ii' •  t  ■  on,.  1  ,uu:  iiv.,  i  c.i  1  1 


I 
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interfaces.  Depending  upon  the  amount  of  pvstem  engineering  that  may  have  been 
completed  and  the  complexitv  of  the  svstem  being  specified,  the  definition 
subparagraphs  may  include:  block  diagrams;  functional  diagrams;  logic  diagrams; 
schematic  diagrams;  specification  frees;  pertinent  organizational,  operation.;!, 
and  logistic  concepts;  identification  of  maior  svstem  segments;  and  an'  otner 
pertinent  descriptive  material. 

These  definition  paragraphs  are  particularly  important  in  a  space  system  speci¬ 
fication.  In  fact,  in  the  initial  draft  of  a  space  system  specification,  sub¬ 
section  3.1,  Definition,  may  have  only  text  because  defining  tbe  svstem  being 
specified  is  always  the  first  step  for  programs  control.  As  the  studies, 
analyses,  and  system  development  progress,  additional  recuirements  can  be 
stated.  Eventua.lly  the  subtier  elements  of  the  svstem  can  be  identified  to 
provide  the  framework  of  standard  terminology  to  be  used.  Bv  that  means  all 
narticipants  can  recognize  common  items,  tasks,  schedules,  costs,  interfaces, 
or  other  common  elements  of  the  system  and  of  the  program.  Although  the 
orimarv  focus  in  these  paragraphs  is  on  the  description  of  the  space  svstem. 
including  its  subtier  elements,  the  svstem  interfaces  with  the  rest  of  the 
world  are  also  to  be  identified.  These  external  interface  descriptions  may 
involve  references  to  other  system  specifications,  or  to  documents  prepared  b” 
other  agencies.  It  is  imnortant  to  recognize  the  "uncontrolled"  nature  of  these 
external  interface  references.  For  example,  a  DoD  space  svstem  specification 
may  describe  an  interface  bv  referencing  ?.  Space  Transportation  Svstem  speci¬ 
fication  issued  by  NASA.  That  reference,  however,  does  not  assure  that  the 
actual  interface  is  as  described  or  that  it  will  not  be  changed  by  NASA  at 
some  later  time. 

In  the  earlv  phases  of  a  system  acquisition,  the  referencing  of  higher  level 
specifications  or  external  documents  is  the  only  reasonable  course  to  follow  in 
describing  the  interfaces.  As  the  acquisition  progresses,  an  effort  should  be 
made  to  eliminate  these  external  "uncontrolled"  references.  This  can  be 
accom.plished  by  the  preparation  and  joint  approval  of  interface  control  docu¬ 
ments.  The  interface  control  documents  could  then  be  referenced  in  the  speci¬ 
fication  or  thev  could  be  the  basis  for  the  direct  incorporation  of  the  defini- 
tized  interface  requirements.  Eventually,  detailed  configuration  item  (Cl) 
specifications  would  be  prepared  for  the  actual  procurement  of  the  various 
system  elements.  These  Cl  specifications  should  be  "stand  alone"  documents  and 
should  not  reference  higher  level  specifications  or  externally  controlled  docu¬ 
ments.  This  practice  avoids  the  possibility  of  two  documents  each  referencing 
the  other,  and  each  document  stating  that  it  takes  precedence  over  the  other 
document . 

By  including  the  definition  in  the  requirements  section  of  the  specification, 
contractors  and  others  using  the  specification  can  recognize  the  intent  tc 
assure  co.npliance  with  the  space  system  de.scription  given.  Although  require¬ 
ments  may  include  definitions,  it  should  be  noted  that  definitions  are  not  an 
appropriate  place  to  include  detailed  design  or  test  requirements.  This  sec¬ 
tion  and  the  subparagraphs  are  definitions  that  are  intended  to  he  descriptions 
of  the  svstem  to  be  fulfilled  by  the  detailed  design,  as  opposed  to  statinc 
"shall"  requirements  or  specifying  a  precise  set  of  verifiable  performance 
requirements. 
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As  shown  in  the  Model  Specification,  3.1,  Svsten  definition,  is  usually  verv 
brie:  with  most  of  the  required  text  entirelv  within  subtier  paragraphs. 

Usually  a  list  of  functional  areas  of  the  svstem  is  included  and  a  list  of 
subtier  elements  of  the  svstem  is  also  included  in  3.1.  These  lists  are  simply 
for  the  convenience  of  those  using  the  specification  and  are  incorporated  into 
the  specification  when  the  information  becomes  available.  For  example,  the 
prime  configuration  items  are  not  usually  identified  precisely  until  after  the 
svstem  specification  has  been  fully  completed.  Of  colirse,  the  lists  shown  in 
the  Model  Specification  are  typical  and  should  be  changed  to  conform  to  the 
particular  system  being  specified. 

Paragraph  3.1.1,  General  description,  is  the  paragraph  that  contains  an  expanded 
description  of  the  system  from  that  given  in  3.1  and  identifies  the  functional 
areas  and  the  relationship  of  the  system  being  specified  to  other  systems.  In 
that  context  the  program  should  be  briefly  described  in  terms  such  that  all 
svsteras  or  other  major  elements  of  the  larger  program  are  identified. 

Paragraph  3.1.2,  Missions,  is  included  to  provide  a  description  of  operational 
missions  and  related  information  that  could  affect  the  design. 

Paragraph  3.1.3,  Threat,  is  included  to  identify  potential  threats  to  the 
system  that  should  be  considered  in  the  design  so  that  the  system  performance 
would  not  be  jeopcrdized  even  if  the  threat  conditions  materialized.  For  space 
elements  it  night  include  nuclear  attack,  pellet  attack,  laser  attack,  elec¬ 
tronic  jamming,  all  of  the  above,  cr  none  of  the  above.  For  ground  elements  it 
might  include  conventional  weapons,  sabotage,  nuclear,  or  whatever.  The  Model 
Specification  takes  the  easy  wav  out  and  suggests  (Not  applicable).  Of  course, 
that  mav  not  be  the  correct  entry  for  a  specific  system. 

Paragraph  3.1.4,  System  diagrams,  should  incorporate  the  top  level  functional 
flow  diagrams.  If  a  top  level  functional  flow  diagram  for  the  program  is  devel¬ 
oped  it  should  be  incorporated  into  this  paragraph.  The  program  level  diagram 
provides  the  framework  for  describing  the  system  being  specified,  the  interfaces 
with  other  svstems,  and  for  expanding  the  functional  flows  to  lower  levels.  In 
anv  case,  the  top-level  functional  flow  diagrams  for  the  system  would  be 
incorporated.  The  system  functional  flow  diagram  should  be  an  expansion  of  the 
applicacie  program  level  functions. 

When  available,  layout  drawings  or  other  graphic  portraval  which  establish  the 
gener.al  relationship  of  functional  areas  and  the  major  elements  of  the  system 
should  be  included. 

WTien  the  subtler  elements  of  the  svstem  have  been  identified,  a  specification 
tree  should  also  be  incorporated.  A  specification  tree  is  a  configuration  item 
oriented  diagram  or  chart  that  shows  the  -.llocated  Cls  that  make  up  the  item 
being  specified.  The  specifications  which  identify  each  subitem  would  be  showTi 
on  the  tree.  Other  .specif  ic.itions  which  serve  to  identify  external  interface.= 
including  the  government-contractor  interfaces  mav  also  be  shown.  The  specifi¬ 
cation  tree  for  the  entire  program  should  be  included,  if  it  is  available,  to 
assist  in  the  identification  of  the  svstem  interfaces.  in  anv  case,  tlie  space 
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system  soecif ication  tree  would  be  incorporated  to  identifv  the  svsteir  segments 
and  as  many  of  the  subtler  CIs  as  possible.  This  specification  tree  for  the 
system  does  not  need  to  be  complete,  particularlv  at  the  lower  tier  levels,  but 
the  CIs  that  can  be  identified  will  provide  a  framework  for  correlating  the 
hardware,  the  statement  of  work  tasks,  the  work  breakdown  structure  (WBS),  the 
cost  reporting  requirements,  the  program  scheduling,  and  the  data  items  required 
to  properly  manage  the  program.  The  specification  tree,  or  equivalent  inden¬ 
tured  list  of  CIs,  is  needed  by  all  of  the  program  participants  as  early  as 
possible  to  serve  as  a  common  means  of  identification  of  the  program  elements. 

If  the  specification  tree  is  depicted  in  a  separate  document  or  drawing  whose 
size  prevents  incorporation  into  the  specification,  it  is  referenced  bv  docu¬ 
ment  or  drawing  number . 


3.  REQUIREMENTS 

3.1  Definition.  The  space  system  is  an  element  of  the  (insert  pro¬ 
gram).  The  system  is  subdivided  into  the  following  system  segments: 

a.  Space  system  segment  which  includes  the  following  identified  con¬ 
figuration  items;  (TBS) 

b.  Ground  terminal  system  segment  which  includes  the  following  con¬ 
figuration  items:  (TBS) 

c.  Data  reduction  svstem  segment  which  includes  the  following  con¬ 
figuration  items;  (TBS) 

3.1.1  General  Description.  (TBS) 

3.1.2  Missions.  (TBS) 

3.1.3  Threat .  (Not  applicable) 

J.1.4  Svstem  Diagrams. 

3  1.4.1  Functional  Flow  Diagrams.  The  top  functional  flow  diagram 
for  t  ■  system  is  shown  in  Figure  1.  First-level  flow  diagrams  for 
operational,  maintenance,  test,  and  activation  functions  are  shown  in 
Figures  2.  3,  4,  and  5.  (TBS) 

3. 1.4. 2  Specif icatlon  Tree.  The  specification  tree  for  this  system 
is  shown  in  Figure  6. 


}:lec:ponic  sy^temo  -  comment: 

Samples  of  functional  flow  block  diagram?  reproduced  from  the  svstem  specifica¬ 
tion  for  a  large  data  processing  system  are  provided  in  Appendix  C  of  this 
made  book. 


83 


Paragraph  3.1.5,  Interface  definitions,  may  be  a  heading  (title)  with  subpara¬ 
graphs,  or  text  may  follow  the  title.  The  paragraph  should  identifv  all  func¬ 
tional  and  physical  interfaces  that  must  be  considered;  however,  the  interfaces 
should  not  be  specified  as  precise  inputs,  outputs,  and  dimensions  that  will 
require  inspection  for  verification.  Usually  references  are  made  to  the  func¬ 
tional  diagrams  and  to  the  specification  tree  included  in  3.1.4  to  help  identify 
the  various  interfaces. 

Interface  control  drawings  and  other  engineering  data  may  be  referenced  if 
helpful  to  define  all  functional  and  physical  interfaces  required  to  make  the 
svstem  compatible  with  other  items.  Although  the  details  of  the  interfaces 
may  be  stated  in  these  referenced  documents,  the  details  should  be  repeated, 
bv  extraction  or  by  reference,  in  the  appropriate  subparagraphs  such  as  in 
3.2,  3.3,  or  3.5  because  paragraph  3.1.5  is  still  part  of  the  definition  sub¬ 
section  . 

At  some  point  in  the  development  of  the  system,  it  will  be  possible  to  identify 
the  interfaces  between  the  subtler  system  segments  that  are  part  of  the  system 
being  specified.  Usually  the  description  of  these  internal  interfaces  would 
reference  the  specification  tree  for  the  space  system  included  in  3.1.4.  As 
with  the  system  external  interfaces,  these  internal  interfaces  are  onlv  defined 
in  this  paragraph  and  must  be  detailed  in  the  3.7  paragraphs  where  the  system 
segment  characteristics  are  stated.  Where  interfaces  may  differ  due  to  changes 
in  operational  mode,  they  shall  be  stated  in  a  manner  which  identifies  specific 
interface  requirements  with  each  different  mode. 


3.1.5  Interface  definitions.  The  space  system  interfaces  with  other 
elements  of  the  space  program  are  defined  in  Figure  7.  (TBS) 

i _ — 


ELECTP.OIilC  SYSTEMS  -  COMMENT: 

Instructions  in  MIL-STU-490  require  that  this  paragraph  not  only  identify  inter¬ 
faces  (a)  with  other  systems  and  (b)  among  major  parts  of  this  system  but  that 
it  also  provide  (either  directly  or  by  reference)  engineering  data  to  define 
both  functional  and  physical  interfaces  precisely.  This  area  poses  many  prob¬ 
lems  and  potential  pitfalls  for  software,  in  particular: 

a.  Tile  normal  e.xpectation  based  on  aerospace  vehicle  and  other  hardware  experi¬ 
ence  is  that  many  of  the  physical  interfaces  will  be  defined  late  in  a 
svstem  nroeram  it)'picany,  ”hv  CDP."1 ,  then  added  to  this  part  of  the  si’stem 
specification  bi'  reference  to  ICDs. 

b.  I'ith  I’en’  few  exceptions,  however,  precise  definitions  of  all  interfaces 
affecting  software  should  be  completed  and  available  for  identification 
in  the  system  specification  by  the  end  of  a  v^alidation  phase.  ICDs  are 
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seldoir.  useful  for  this  purpose  (for  further  discussion  of  considerations 
pertaining  to  software/software  and  software/hardware  interfaces,  see 
ref.  18,  para.  3.4") . 

c.  Interface  information  for  a  large  electronic  system  is  t>pically  extensive. 
Careful  planning  is  needed  to  avoid  unnecessary  redundancy,  as  well  as  the 
frequent  errors  of  inaccuracy  and  omissions.  "Interfaces"  are  also  perfor¬ 
mance  characteristics  to  be  specified  in  3.2.1,  and  further  amplified  for 
each  system  segment  in  3.7.  Although  inconvenient  to  users,  the  libe’-al 
use  of  cross-referencing  is  often  preferable  to  repeating  the  same  precise 
definitions  in  multiole  locations. 


Paragraph  3.1.6,  Government  furnished  property  list,  usually  only  consists  of 
a  list  of  the  Government  furnished  property  which  the  system  shall  be  designed 
to  incorporate.  This  list  must  identify  the  property  by  reference  to  its 
nomenclature,  specification  number,  and  item  number  if  available.  If  the  list 
is  extensive,  it  may  be  included  in  an  appendix  or  in  a  separate  specification 
supplement  or  other  document  which  would  then  be  referenced  in  this  paragraph. 
The  list  in  the  Model  Specification  is  typical  and  should  be  changed  to  conform 
to  the  particular  system.  Specific  quantitites,  including  spares,  should  be 
indicated.  If  there  is  Government  property  that  is  essential  to  the  system 
development  that  can  be  loaned  for  that  purpose,  it  should  be  listed  separatelv 
in  this  paragraph.  Government  property  which  can  be  made  available  to  support 
the  system  and  can  be  loaned  to  the  contractor  might  include  computers,  soft¬ 
ware,  tools,  and  trailers.  Often  the  correct  entry  under  the  "For  loan" 
heading  is  (Not  applicable) .  The  schedule  of  availability  and  associated 
costs,  if  any,  for  the  use  of  Government-loaned  propertv  should  not  be  stated 
in  the  specification. 
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3.1.6  Government  furnished  property  list. 

3. 1.6.1  For  incorporation.  The  following  GFP  shall  be  incorporated 
into  the  system  as  indicated: 

a.  COMSEC  equipment  (TBS) 

b.  Rocket  motors  (TBS) 

c.  Explosive  ordnance  (TBS) 

d.  Payload  equipment  (TBS) 

e.  Propellants  (TBS) 

3. 1.6. 2  For  loan.  The  following  Government  property  mav  be  loaned 

for  use  in  developing  the  system:  (TBS) 
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Paragraph  3.1.7,  Operational  and  organizational  concepts,  is  usually  included 
in  a  system  specification  to  provide  operational  infoinnatior.  that  could  help 
define  the  system  and  that  could  affect  the  design  such  as: 

a.  The  basic  performance  parameters  upon  which  the  using  activities 
can  base  tactics  which  utilize  the  capabilities  of  the  system  and 
which  should  be  recognized  in  the  design. 

b.  Description  of  the  mission  in  terms  of  relationships  to  other  items 
of  the  system  or  to  other  systems. 

c.  Anticipated  deployment  of  the  system  equipments,  both  geographically 
and  organizationally,  such  as  the  number  of  operational  vehicles, 
number  of  ground  support  installations  and  their  operating  locations. 

Note  that  the  Model  Specification  provides  general  words  for  a  space  system 
where  the  space  vehicle  is  launched  using  either  the  Space  Transportation 
System  (STS)  or  is  launched  using  an  expandable  launch  vehicle.  The  require¬ 
ments  should  of  course  be  worded  to  reflect  the  actual  operational  concept. 

In  addition,  any  organizational  concepts  that  could  affect  the  design  should 
be  included  in  added  paragraphs. 


3.1.7  Operational  and  organizational  concepts.  The  system  supports  a 
space  vehicle  launch  and  possible  retrieval  using  the  Space  Transportation 
System  (STS)  or  for  launch  using  the  (TBS)  expandable  launch  vehicle. 
On-orbit  operations  are  planned  to  be  controlled  from  the  mission  control 
center  (MCC)  located  (TBS)  and  remote  tracking  stations  (TBS). 

3. 1.7.1  STS  operational  concept.  The  following  STS  operational  con¬ 
cept  is  supplied  as  a  guide  for  use  in  the  system  design  and  for  the 
preparation  of  operational  plans  and  test  plans: 

3. 1.7. 1.1  STS  prelaunch.  The  space  vehicle  would  be  transported  from 
storage  or  directly  to  the  launch  base  where  final  space  vehicle  prepara¬ 
tions  and  checkout  would  be  accomplished  at  the  Payload  Preparation  Room 
of  the  STS  launch  facility.  Final  intersegment  and  launch  verification 
tests  would  be  accomplished  after  space  vehicle  and  associated  equipment 
installation  in  the  STS  and  prior  to  launch. 

3. 1.7. 1.2  STS  launch.  During  STS  ascent  to  the  parking  orbit,  various 
space  vehicle  .subsystems  or  system  equipments  may  be  powered  on  or  turned 
off  in  order  to  provide  protection  from  the  STS  environments  or  to  comply 
with  STS  safety  requirements.  Space  vehicle  telemetry  to  monitor  vehicle 
status  would  be  provided  to  the  STS  for  monitoring  and  retransmission  (in 
real  time  or  playback)  to  the  ground  monitoring  stations. 

3. 1.7. 1.3  STS  parking  orbit  operations.  VJliile  the  space  vehicle  is 
attached  to  the  STS,  vehicle  telemetry  to  monitor  vehicle  status  continues 
to  be  provided  to  the  STS  for  monitoring  and  retransmission  (in  real  time 
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or  playback)  to  the  ground.  When  the  space  vehicle  is  released  from  the 
STS,  responsibility  for  monitoring  and  control  would  be  transferred  to  the 
ground  mission  control  center  (MCC) .  The  STS  may  provide  assistance  for 
th»  resolution  of  anomalies  when  requested  by  the  MCC.  In  the  event  of 
unsatisfactory  deployment  or  unsatisfactory  space  vehicle  checkout,  the  STS 
would  retrieve  the  vehicle  and  return  to  the  launch  site. 

3. 1.7. 1.4  Space  vehicle  orbit  injection.  After  release  bv  the  STS  and 
successful  vehicle  checkout  and  appendage  deployment,  the  vehicle  would 
boost  itself  (or  would  be  boosted)  into  its  operational  orbit  under  command 
from  the  ground. 

3. 1.7. 2  Expendable  launch  vehicle  operational  concept.  When  the  use  of 
an  expendable  launch  vehicle  is  planned,  the  following  operational  concept 
is  the  guide  for  use  in  the  system  design  and  for  the  preparation  of  opera¬ 
tional  plans  and  test  plans:  (TBS) 

3. 1.7. 2.1  Prelaunch.  The  space  vehicle  would  be  transported  from 
storage  or  directlv  to  the  launch  base  where  final  vehicle  preparations  and 
checkout  would  be  accomplished  on  the  launc’-.  vehicle  after  mating.  Final 
intersegment  and  launch  system  verification  tests  are  accomplished  prior  to 
launch. 

3. 1.7. 2. 2  Launch  and  injection.  During  launch  and  injection  to  the 
operational  orbit,  the  various  vehicle  subsystems  may  be  powered  on  or 
turned  off  in  order  to  provide  protection  from  the  launch  and  injection 
environments  or  to  comply  with  other  specified  requirements.  Space  vehicle 
telemetrv  to  monitor  vehicle  status  would  be  provided  during  launch  anri 


3. 7. 3. 3  Mission  completion.  At  the  completion  of  the  space  vehicle 
mission,  the  space  vehicle  would  be  either  deboosted  to  the  STS  retrieval 
orbit,  de-orbited,  or  all  equipment  would  be  commanded  off.  For  STS  re¬ 
trieval,  the  space  vehicle  provides  space  vehicle  safety  status  and  other 
required  verification  data  to  the  STS.  Once  captured,  the  space  vehicle 
would  be  stored  in  the  STS  payload  bay.  In  the  event  of  an  unsuccessful  STS 
retrieval,  the  space  vehicle  would  be  de-orbited.  At  the  appropriate  point 
in  the  orbit  the  STS  would  de-orbit  and  return  to  VAFB.  After  STS  rolicut 
and  safing,  the  STS  would  be  brought  to  the  STS  Processing  Facility  where 
the  space  vehicle  would  be  removed  and  processed  for  transportation  to  the 
factory.  Also,  in  the  event  of  an  aborted  STS  launch,  it  would  be  at  this 
point  that  the  space  vehicle  would  be  recycled  back  to  the  launch  pad  or  to 
the  factory.  (Where  mission  completion  consists  of  command  all  equipment 
off,  that  should  be  specified  instead  of  retrieval  or  de-orbit.  Where  it 
is  planned  that  a  space  vehicle  launched  using  an  expendable  launch  vehicle 
mav  be  retrieved  or  serviced  using  the  STS,  specific  on-orbit  or  mission 
completion  requirements  would  be  described.) 


Subsection  3.2,  Characteristics.  This  subsection  generally  starts  with  a  title 
heading  for  the  paragraphs  that  follow.  The  intent  of  the  material  included  in 
this  subsection  is  to  clearly  state  in  quantitative  terms  the  pertinent  oer- 
formance  requirements  and  physical  characteristics  of  the  system.  Requirements 
that  are  applicable  to  a  system  segment  or  to  a  single  prime  Cl,  such  as  the 
space  vehicle,  should  be  stated  in  the  appropriate  paragraph  in  subsection  3.7 
and  not  in  this  subsection. 

Paragraph  3.2.1,  Performance  characteristics,  includes  general  and  detail 
requirements,  under  appropriate  subheadings,  for  all  performance  requirements, 
i.e..  what  is  expected  of  the  system  including  both  the  range  of  values  and 
tolerances.  Again  note  that  the  combined  performance  of  the  entire  system,  or 
at  least  that  of  two  or  more  of  the  system  segments,  are  addressed  in  this  para¬ 
graph  and  the  subparagraphs.  The  performance  of  a  single  system  segment  or  of 
an  individual  Cl  would  be  addressed  in  subsection  3.7.  Other  subparagraphs  for 
other  nerformance  characteristics  may  be  added  in  this  subsection  depending  upon 
the  system.  Other  typical  headings  may  include  deployment,  instrumentation, 
design  commonality,  and  reference  timelines. 

Paragraph  3. 2. 1.1,  Operational  phases  and  modes,  identifies  each  of  the  opera¬ 
tional  phases  and  modes.  Phases  may  include  launch,  on-orbit,  ground  operations, 
reentry,  and  recovery  although  there  may  be  other  phases  that  could  be  approori- 
ate  to  a  particular  system  such  as:  (a)  surveillance,  (b)  threat  evaluation, 

(c)  target  designation  and  acquisition,  (d)  weapon  deployment,  and  (e)  data 
reduction.  Modes  may  include  various  configurations,  power  levels,  or  other 
differences  that  may  occur  during  one  of  the  phases  that  requires  special  design 
attention. 

Paragraph  3. 2. 1.2,  Dynamic,  states  the  system  dynamic  performance  parameters 
required  for  each  phase  and  mode. 

Paragraph  3. 2.  1.3,  Endurance,  states  the  Quantitative  criteria  covering  endur¬ 
ance  capabilities  of  the  system  required  to  meet  user  needs  under  stipulated 
environmental  and  other  conditions,  including  minimum  total  life  expectancy. 

The  required  mission  duration  and  planned  utilization  rate  in  the  various  modes 
should  be  indicated.  The  endurance  requirements  stated  in  the  Model  Specifica¬ 
tion  are  tvplcal  and  .should  be  changed  to  the  times  and  reouirements  of  the 
specific  svstem. 


3 . 2  Characteristics . 

3.2.1  Performance . 

3. 2. 1.1  Operational  Times  and  Modes.  (TBS) 

3. 2. 1.2  Dynamic .  (TBS) 

Endurance .  The  ground  based  elements  of  the  svstem  shall  have 
a  design  service  life  of  20  vears.  The  eleraents  of  the  svstem  associated 
,ii[i  the  STS  Orbiter  operations  shall  havj  a  desiqn  service  life  of  15 
vears.  The  on-orhit  design  life  of  the  space  vehicle,  as  mav  be  limited  bv 
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mechanical  wearout ,  battery  life,  solar  array  life,  or  the  exhaustion  of 
expendables,  shall  be  no  less  than  five  years.  The  design  of  the  space 
vehicle  shall  be  such  that  space  vehicle  storage,  under  controlled  condi¬ 
tions,  may  be  planned  for  as  long  as  four  years.  The  design  service  life 
of  the  space  vehicle  shall  be  ten  years  based  on  the  sum  of  the  allowed 
storage  time,  pre-launch  checkout  time,  launch  and  injection  time,  on-orbit 
time,  recoverv  time,  and  contingency  time.  (TBS) 

I 

3.2.1.^  Other.  (TBS) 


ELECTRONIC  SYSTEMC  -  COMMENT 


Note  that  the  performance  requirements  to  be  soecified  here  are  those  which  per¬ 
tain  to  the  system  as  a  whole,  or  are  common  to  two  or  more  segments.  These  are 
later  apportioned  to  each  system  segment  (in  subsection  3.7),  normally  by  refer¬ 
ence  to  this  paragraph,  together  with  additional  requirements  peculiar  to  the 
individual  segments.  Jointly,  the  performance  requirements  set  forth  here  and 
in  3.”  constitute  the  pr'inaipal  aontent  of  the  suetejv  specification  as  a  whole 
as  it  pertains  to  requirements  for  system  software.  These  are  the  requirements 
upon  which  development  (TjqDe  B5)  specifications  for  CPCIs  will  be  based.  The 
information  should  normally  be  extensive,  in  that  it  should  provide  a  definitive 
translation  of  operational,  organizational,  and  supoort  concepts  described  in 
the  preceding  paragraph  3.1  into  a  complete  set  of  imiilementing,  data  nrocessing 
operations. 

All  system  functions  required  to  perform  the  mission  described  previously  in 
paragraph  3.1  are  to  be  identified.  A  subparagraph  should  be  devoted  to  each 
function  which  specifies  required  performance  associated  with  the  function  in 
terms  of  capacities,  loads/volumes  of  data,  reaction  times,  accuracies,  and 
other  relevant  characteristics.  The  proper  "level"  at  which  these  requirements 
should  be  specified  varies  with  the  system  and  particular  function  being  speci¬ 
fied.  Generally,  the  objective  is  to  define  required  system  capabilities 
comprehensively,  but  at  the  same  time  to  avoid  details  which  can  be  amplified 
later  within  the  intended  scope.  As  an  example: 

"Each  intercept  direction  center  shall  be  capable  of  scrambling  intercep¬ 
tors  from  up  to  6  airbases.  ...  Guidance  commands  shall  be  computer¬ 
generated  and  displayed  to  weapons  team  personnel  to  permit  voice  control 
of  manned  interceptors  on  (tj^ies  of  missions,  tijies  of  interceptors,  num¬ 
ber  of  interceptors  controlled,  frequency  of  computed  commands,  handling 
of  aborted  missions,  etc.  i  ...  klien  interceptors  follow  the  commands,  the 
following  accuracies  shall  be  achieved  at  least  871  of  the  time:  The 
difference  between  actual  and  specified  crossing  angle  at  rollout  shall  be 
less  than  15  degrees;  The  intercept  rollout  point  shall  be  within  4.5 
miles  of  the  desired  rollout  point;  ..." 

Such  requirements,  at  the  systeir  level,  are  adequate  to  dictate  the  scone  and 
nature  of  amplifying  detail  which  will  then  have  to  be  dev-eloned  for  documen¬ 
tation  in  the  T^'ne  E3  specification  for  a  CPCI.  The  latter  must  "fill  in" 
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extensive  data  to  define,  for  example:  quantitative  flight  characteristics  of 
each  specified  interceptor  tN’pe,  together  with  tracking  and  other  essential 
inputs  to  the  command  computations;  mathematical  formulas  ("not  algorithms]  for 
the  computations,  including  timing  and  accuracies;  types  of  operating,  alarm, 
and  other  controller  displays,  together  with  detailed  formats  and  contents  as 
a  function  of  operating  mode,  intercept  phase,  and  contingencies. 


Paragraph  3.2.2,  Physical  characteristics,  sets  forth  physical  requirements  in 
the  appropriate  subheadings  that  are  applicable  to  two  or  more  of  the  system 
segments.  Physical  characteristics  include  such  items  as  weight  limits  and 
dimensional  limits  necessary  to  assure  physical  compatibility  with  other  pro¬ 
gram  elements  and  not  determined  by  other  design  and  construction  features  or 
referenced  drawings.  The  paragraphs  may  also  include  considerations  such  as 
tie  down  requirements  for  transportation,  security  criteria,  durability  fac¬ 
tors,  health  and  safety  criteria,  survivability,  and  vulnerability  factors. 

The  physical  characteristic  requirements  of  a  single  system  segment  or  of  indi¬ 
vidual  CIs  would  be  addressed  in  subsection  3.7  of  the  specification.  Addi¬ 
tional  subparagraphs  may  be  provided  depending  on  the  system. 

Paragraph  3. 2. 2.1,  Mass  properties,  states  requirements  for  limiting  and  con¬ 
trolling  the  mass  properties  of  the  system  elements.  Usually  general  require¬ 
ments  are  stated  for  space  elements  such  as  the  space  vehicle,  the  space 
vehicle  support  equipment  for  use  in  the  STS  orbiter,  and  for  the  payload.  In 
addition,  general  mass  property  requirements  for  fixed  and  mobile  ground  equip¬ 
ment  is  usually  stated  to  avoid  excessive  floor  or  road  loading  or  to  allow 
transportability. 

Paragraph  3. 2. 2. 2,  Dimensions,  identifies  the  coordinate  systems  used  in  the 
system  and  any  envelope  constraints  imposed  on  the  system. 

Paragraph  3. 2. 2. 3,  Power,  states  the  requirements  both  for  external  electrical 
power  to  be  supplied  to  the  various  elements  of  the  system  and  for  power  to  be 
generated  by  the  various  elements  of  the  system  and  supplied  to  other  items, 
lare  should  be  taken  to  distinguish  between  power  supplied  to,  and  power  being 
supplied  from,  each  of  the  system  items  during  each  of  the  operating  modes. 

Paragraph  3. 3. 3.4,  Durability,  is  a  general  motherhood  requirement  intended  to 
inaicate  the  degree  of  ruggedness  required. 

Paragraph  3. 2. 2. 5,  Survivability,  is  where  requirements  would  be  stated  for 
consideration  atomic,  chemical,  biological,  radiological,  fire,  and  impact 
vulnerability  and  survivability. 


3.2.2  Physical  characteristics 

3.2.2. 1  Mass  properties.  The  mass  properties  of  the  space  elements 
shall  be  determined  in  accordance  with  MIL-M-383in.  The  weight  of  the 
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space  vehicle  shall  not  exceed  (TBS).  The  weight  of  the  space  elements 
shall  be  controlled  for  the  preservation  of  performance  margins  and  as  a 
control  of  other  mass  properties.  The  recommended  weight  contingency  for 
space  elements  is  as  follows; 

a.  Preliminary  design  -  new  equipment  20  per  cent 

GFE  &  existing  equipment  5  per  cent 

b.  Critical  design  -  new  equipment  10  per  cent 

CFE  &  existing  equipment  3  per  cent 

c.  Final  design  -  new  equipment  5  per  cent 

GFE  {.  existing  equipment  2  per  cent 

The  mass  properties  of  ground  elements  of  the  system  shall  be  consistent 
with  their  Intended  application.  The  weight  of  hand  carried  equipment 
shall  not  exceed  10  kilograms  (kg).  The  center  of  gravitv  of  ground  equip¬ 
ment  shall  be  such  that  probable  seismic  activity  will  not  cause  the  equip¬ 
ment  to  upset.  The  weight  of  ground  elements  shall  be  controlled  to  avoid 
excessive  floor  loading  for  fixed  equipment  and  excessive  road  loading  for 
mobile  equipment.  The  weight  of  all  equipment  shall  allow  transportability 
by  truck  and  C-5  aircraft. 

3. 2. 2. 2  Dimensions .  The  coordinate  definitions  and  envelope  con¬ 
straints  for  the  system  shall  be  as  shown  in  Figure  3.  For  the  spaceborne 
elements,  the  envelope  constraints  shall  be  based  upon  the  dynamic  enve¬ 
lopes  encountered  during  factory  assembly,  system  test,  transportation, 
integration  with  the  booster,  launch,  and  other  phases  of  operations. 

3. 2. 2. 3  Power .  The  primary  electrical  power  on  the  space  vehicle 
shall  be  in  accordance  with  MIL-STD-1539 .  The  primary  electrical  power 
supplied  to  the  system  equipment  mounted  in  the  STS  Orbiter  shall  be  (TBS) . 
The  primary  electrical  power  supplied  to  the  ground  based  elements  of  the 
system  shall  be  (TBS). 

3. 2. 2. 4  Durability .  The  system  equipment  shall  be  so  designed  and 
constructed  that  no  fixed  part  or  assembly  shall  become  loose,  no  movable 
part  or  assembly  shall  become  undesirably  free  or  sluggish,  and  no  degrada¬ 
tion  shall  be  caused  in  the  performance  beyond  that  specified  for  the 
system  equipment  during  operation  or  after  storage. 


Paragraph  3.2.3,  Reliability,  and  the  subparagraphs  state  requirements  for  the 
reliability  of  the  system  to  perform  within  specified  limits  for  the  service 
life  of  the  system.  Other  subparagraphs  may  be  added  to  cover  areas  other 
than  MTBF  and  redundancy. 

Paragraph  3. 2. 3.1,  Mean  time  between  failures,  is  where  KTBF  reauirement.s  are 


stated  for  the  system.  The  "boilerplate"  in  the  Model  Specification  is  typical, 
but  should  be  changed  for  each  program. 

Paragraph  3. 2. 3. 2,  Redundancy,  is  a  typical  general  statement  of  redundancy 
requirements  for  all  elements  of  a  space  system.  Specific  requirements  may  be 
added,  or  changes  to  the  "boilerplate"  may  be  made  based  upon  the  system 
requirements . 

Paragraph  3.2.4,  .Maintainability,  specifies  the  quantitative  maintainability 
requirements  in  the  planned  maintenance  and  support  environments.  The  require¬ 
ments  may  include  such  items  as: 

a.  Time  values  for  mean  and  maximum  down  time,  for  mean  times  between 
maintenance  actions,  for  mean  and  maximum  times  to  repair,  for  reaction 
times,  and  for  turnaround  times. 

b.  Rate  values  indicating  frequency  of  preventative  maintenance,  for 
maintenance  man  hours  per  specific  maintenance  action. 

c.  Maintenance  complexity  including  numbers  of  people,  skill  levels,  and 
variety  of  support  equipment. 

d.  Maintenance  action  indices  including  maintenance  costs  per  operating 
hour  and  man  hours  per  overhaul. 

Note  that  contractor  maintenance  is  generally  applicable  to  space  systems  and 
that  the  same  maintainability  requirements  are  not  usually  applicable  to  all 
elements  of  the  svstem. 


3.2.3  Reliability .  The  reliability  allocations  shall  assure  that  the 
overall  mission  reliability  requirements  are  met  under  the  most  severe 
extremes  of  storage,  transportation,  testing,  and  operations.  To  the  extent 
practicable,  the  system  design  shall  be  such  that  a  failure  in  one  component 
snail  not  propagate  to  other  devices  or  components,  l-ihere  practicable,  the 
space  vehicle  shall  be  capable  of  detecting  malfunctions  while  in  orbit  and 
automatically  initiating  protective  measures  to  avoid  catastrophic  loss  of 
the  space  vehicle. 

3. 2. 3.1  Mean  time  between  failures.  The  mean  time  between  failures 
for  the  elements  of  the  system  shall  be  analytically  determined  for  each 
operating  mode.  Piece  part  or  component  failure  rates  obtained  from  actual 
usage  data  shall  be  used  where  available.  Failure  rates  estimated  from 
.standard  data  sources  evaluated  at  anticipated  onerating  conditions  shall 
tie  used  when  data  under  actual  usage  is  nonexistent  or  inadequate.  The 
svstem  reliability  shall  be  evaluated  in  terms  of  events  and  usage  cycles 
I  that  occur  during  a  typical  service  life  cvcle. 
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The  space  vehicle  probability  of  survival  curve  shall  be  represented  bv  its 
equivalent  Welbull  function: 


R(t) 


where  a 


scale  paratnetev 
shape  parameter 


The  space  vehicle  probability  of  survival  for  the  nominal  service  life 
bb.all  be  at  least  0.5  assuming  the  probability  of  launch  success  to  be  at 
least  0.98.  The  space  vehicle  probability  of  survival  shall  include  con- 
j  Fideration  of  anv  potential  failures  in  associated  ground  operations,  such 
I  as  coTnmanding,  that  might  not  be  corrected  in  time  to  avoid  an  impact  on 
i  the  space  vehicle. 

I 

3. 2. 3. 2  Redundancy .  Redundancy  to  eliminate  single  point  failure 
modes  may  be  incorporated  to  meet  the  reliability  requirements,  unless  the 
addition  of  redundancy  actually  reduces  overall  reliability  due  to  the 
added  complexity.  For  designs  that  switch  redundant  units,  components,  or 
subassemblies  autonomously,  or  by  command,  the  failure  rates  for  the 
switching  circuits,  and  for  the  redundant  equipment  while  in  the  off-line 
mode,  shall  be  appropriately  included  in  the  reliability  determination. 
UTiere  practicable,  provisions  shall  be  incorporated  to  verify  the  operation 
of  all  switchable  redundant  paths  without  disassembly. 

3.2.4  Maintainability.  To  the  extent  practicable,  the  spaceborne  ele¬ 
ments  of  the  system  shall  be  designed  so  as  not  to  require  any  scheduled 
maintenance  or  repair  during  their  service  life.  I'Jhere  practicable,  the 
design  of  space  elements  shall  incorporate  test  and  telemetry  points  to 
allow  verification  of  functional  performance  and  shall  accommodate  easy 
installation  and  replacement  of  major  subassemblies.  The  ground  based 
elements  shall  be  designed  with  self  test  features.  The  ground  based  ele¬ 
ments  shall  be  designed  using  modular  construction  for  ease  of  maintenance 
to  assure  the  equipment  availability  required  to  achieve  the  specified 
service  life  and  mission  reliability. 


Paragraph  7.2.5,  Availability,  states  the  availability  requirements  that  may 
include  availability  for  on-orbit  operations,  for  launch  readiness,  and  for 
recovery.  Availability  is  the  degree  to  which  the  system  must  be  in  an  oper¬ 
able  and  c.ommittable  state  at  the  start  of  a  mission  where  the  mission  is 
called  for  at  an  unknown  or  random  point  in  time.  When  the  STS  is  used,  there 
are  limitations  imposed,  particularly  during  the  prelaunch  and  launch  sequence, 
or.  access  or  availability  of  the  system  soace  equipment  for  test  or  mainte¬ 
nance  activities,  ^■/hen  applicable,  these  limitations  should  be  stated  in  this 
paragraph  because  of  their  possible  imn.tct  on  the  space  equipment  design  and 
or;  tne  design  and  location  requirements  for  ground  support  equinment. 
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Paragraph  3.2.6  System  effectiveness,  is  marked  (Not  applicable)  because  there 
is  not  a  consensus  as  to  what  it  means.  If  there  are  requirements  relating  to 
system  effectiveness  that  are  not  covered  in  other  paragraphs,  they  should  be 
included  in  this  paragraph. 

Paragraph  3.2.7,  Environmental  conditions,  and  the  subparagraphs  provide  for 
statements  of  the  various  environmental  levels  for  the  system  during  the  various 
operating  phases.  If  environmental  levels  are  specified,  they  should  be  the 
design  levels  that  include  the  desired  margins.  VThere  various  levels  are  pos¬ 
sible  during  a  phase,  the  environmental  levels  specified  should  be  a  composite 
that  covers  the  maximum  and  minimum  values.  If  the  use  of  composite  values  is 
not  appropriate,  a  further  subdivision  should  be  used  to  make  the  necessary 
distinction  in  design  levels  for  the  various  configurations  or  categories.  If 
the  system  segments  are  different  from  each  other,  the  environmental  conditions 
would  be  addressed  only  in  3.7.  This  paragraph  would  then  state  "(see  3.7)". 

Paragraph  3.2. 7.1,  Launch  environments,  is  intended  to  present  the  design 
environmental  requirements  for  all  system  items  that  undergo  launch.  This  would 
be  specified  as  Che  STS  payload  environment  for  STS  launches,  the  launch  envir¬ 
onment  inside  the  nose  fairing  for  an  expendable  booster  if  that  is  appropriate, 
or  it  would  be  a  composite  of  both  launch  modes. 

Paragraph  3. 2. 7. 2,  On-orbit  environments,  states  Che  design  environmental 
requirements  for  orbiting  elements  of  the  space  system.  This  could  include 
separation  from  the  STS,  injection,  various  on-orbit  modes,  and  recapture  by 
the  STS  as  may  be  appropriate  for  the  particular  program. 

Paragraph  3. 2. 7. 3,  Ground  environments,  specifies  the  design  environmental 
requirements  for  the  various  elements  of  the  space  system  that  are  intended  for 
ground  installation  and  use.  However,  note  that  the  orbiting  elements  of  the 
space  system  also  have  a  ground  environment  prior  to  launch  and  possibly  after 
return  from  orbit.  If  any  of  the  handling,  transportation,  or  other  ground 
environments  for  any  of  the  orbiting  elements  exceed  the  design  values  specified 
for  launch  or  on-orbit,  then  those  ground  environments  should  be  specified. 
Either  added  environmental  protection  could  then  be  developed  for  ground  opera- 
tion.s  or  the  ground  environments  would  be  considered  in  the  design  of  the 
orbiting  elements. 

Paragraph  3. 2. 7. 4,  Other  environments,  is  intended  to  specify  the  design 
environmental  requirements  for  the  various  elements  of  the  space  system  during 
other  applicable  phases  not  covered  by  launch,  on-orbit,  or  ground,  such  as 
reentrv  or  crash. 


3.2.5  Availability.  (TBS) 

3.2.6  System  effectiveness.  (Not  applicable) 

3.2.7  Environmental  conditions.  To  provide  a  design  factor  of  safety 
or  margin,  the  various  system  CIs  and  their  components  shall  be  designed  to 
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function  during,  or  if  appropriate  following,  exposure  to  environmental 
levels  that  exceed,  by  the  specified  margins,  the  maximum  levels  predicted 
for  all  applicable  operational  modes  during  the  service  life  of  the  Cls. 
Unless  otherwise  specified,  the  maximum  predicted  environments  for  the 
spaceborne  equipment  shall  be  determined  in  accordance  with  the  definitions 
in  MIL-STD-1540.  T-/here  practicable,  each  space  component  shall  be  designed 
to  operate  continuously  within  an  ambient  temperature  range  of  at  least  -36 
deg  C  to  +71  deg  C  and  at  ambient  pressures  between  sea  level  and  deep 
space. 

3. 2. 7.1  Launch  environments.  The  space  elements  shall  be  designed  to 
function  within  performance  specifications  after,  or  if  appropriate  during, 
exposure  in  the  launch  configuration  to  environmental  levels  that  exceed 
the  maximum  predicted  launch  environments  by  the  design  factor  of  safety  or 
design  margin. 

3. 2. 7. 2  On-orbit  environment.  The  space  elements  shall  be  designed  to 
function  within  performance  specif ications  following,  or  if  appropriate 
during,  exposure  in  the  on-orbit  configuration  to  environmental  levels  that 
exceed  the  maximum  predicted  on-orbit  envlronemnts  by  the  design  factor  of 
safety  or  design  margin. 

3. 2. 7. 3  Ground  environments.  These  environments  are  those  associated 
with  all  operations  of  ground  equipment  and  the  operation  on  the  ground  of 
the  space  equipment,  including  storage,  transportation,  and  prelaunch 
operations.  The  system  Cls  shall  be  designed  to  function  within  perfor¬ 
mance  specifications  following,  or  if  appropriate  during,  exposure  in  the 
ground  configuration  to  environmental  levels  that  exceed  the  maximum  pre¬ 
dicted  ground  environments  by  the  design  factor  of  safety  or  design  margin. 


Paragraph  3.2.8,  Nuclear  control  requirements,  states  the  general  boilerplate 
requirements  for  controlling  nuclear  material.  These  requirements  may  include 
component  design,  in-flight  controls,  and  safety-related  requirements. 

Paragraph  3.2.9,  Transportability,  states  the  requirements  for  system  trans¬ 
portability.  Make  sure  the  last  sentence  in  the  boilerplate  is  consistent 
with  the  ground  environmental  provisions  specified  in  3. 2. 7. 3. 

Subsection  3.3,  Design  and  construction.  This  subsection  generally  start.s  with 
a  title  heading  for  the  paragraphs  that  follow.  The  Intent  of  the  paragraphs 
included  in  this  subsection  is  to  clearly  state  design  and  construction  require 
ments  and  constraints  that  may  be  applicable  to  the  system  as  a  whole  or  to 
more  than  one  system  segment.  Design  or  construction  requirements  that  are 
applicable  to  a  single  system  segment  or  to  a  single  Cl  should  be  stated  in 
3.7,  not  here. 


Paragraph  3.3.1,  Parts,  materials,  and  processes,  and  the  subparagraphs  are 
general  boilerplate  requirements  for  the  system.  Deletions  or  additions  should 
be  made  where  appropriate  to  satisfy  the  requirements  for  a  particular  system. 

If  the  paragraphs  are  not  applicable  they  should  be  so  marked.  Note  that  the 
management  task  of  establishing  a  parts,  materials,  and  processes  control  pro¬ 
gram  is  not  included  in  the  specification,  but  would  be  stated  as  a  task  in  the 
SOW  when  it  is  a  formal  requirement. 

Paragraph  3.3.2,  Electromagnetic  compatibility,  states  the  general  requirements 
for  EMC.  If  there  are  tempest  requirements  imposed  on  the  system  they  would  be 
stated  also. 

Paragraph  3.3.4,  Workmanship,  states  the  general  workmanship  requirements 
including  the  workmanship  requirements  for  development  models  or  prototypes  to 
be  produced  during  the  system  development. 

Paragraph  3.3.5,  Interchangeability,  specifies  the  requirements  for  the  level  at 
which  components  shall  be  interchangeable  or  replaceable.  Entries  in  this  para¬ 
graph  are  for  the  purpose  of  establishing  a  condition  of  design,  and  are  not  to 
define  the  conditions  of  interchangeability  that  are  required  by  the  assignment 
of  a  part  number. 

Paragraph  3.3.6,  Safety,  states  the  safety  design  requirements  for  avoiding 
hazards  to  personnel  and  equipment.  Safety  related  requirements  applicable  to 
a  single  functional  area  should  not  be  addressed  in  this  paragraph,  but  would 
be  stated  with  the  requirements  for  the  functional  area  (in  3.7).  Note  that  the 
management  task  of  establishing  a  safety  program  based  upon  an  approved  safety 
plan  is  not  included  in  the  specification.  If  the  management  of  a  safety  pro¬ 
gram  is  desired,  it  would  be  stated  as  a  task  in  the  SOW  and  approval  of  the 
safety  plan  would  be  required  by  an  appropriate  entry  on  the  CDRL. 

Paragraph  3.3.7,  Human  performance/human  engineering,  states  general  boilerplate 
requirements  for  accommodating  man-equipment  interactions.  This  paragraph 
should  also  specify  any  special  or  unique  requirements  such  as  any  constraints 
on  allocation  of  functions  to  personnel  and  verbal  communications.  Specific 
areas,  stations,  or  equipment  that  require  concentrated  human  engineering 
attention  to  avoid  critical  human  errors  should  be  identified. 

Paragraph  3.3.8,  Computer  programming,  states  general  requirements  applicable 
to  computer  programs  to  be  developed  as  elements  of  the  system.  These  may 
include  use  of  standard  programming  languages,  objectives  for  modular  design, 
and  other  design  characteristics  considered  essential  to  minimize  program 
errors  or  facilitate  their  later  operational  use  and  support. 


3.3  Design  and  construction 


3.3.1  Parts,  materials,  and  processes.  Unless  otherwise  specified  in 
the  contract,  the  parts,  materials,  and  processes  shall  be  selected  and 
controlled  in  accordance  with  contractor  established  and  documented  proce¬ 
dures  to  satisfy  the  specified  requirements.  The  selection  and  control 
procedures  shall  emphasize  quality  and  reliability  to  meet  the  mission 


requirements  and  to  minimize  total  life  cycle  cost  for  the  system.  An 
additional  objective  in  the  selection  of  parts,  materials,  and  processes 
shall  be  to  maximize  commonality  and  minimize  the  variety  of  parts,  related 
tools,  and  test  equipment  required  to  fabricate,  install,  and  maintain  the 
system.  However,  identical  electrical  connectors,  identical  fittings,  or 
other  identical  parts  shall  not  be  used  where  inadvertent  interchange  of 
items  or  connectors  could  cause  possible  malfunction. 

3. 3. 1.1  Structural  materials.  Materials  shall  be  corrosion  resist¬ 
ant,  or  shall  be  suitably  treated  to  resist  corrosion  when  subjected  to  the 
specified  environments.  Structural  properties  of  materials  for  use  in 
space  applications  shall  be  taken  from  MIL-HDBK  5  for  metals  and  from  MIL- 
HDBK-17,  Parts  1  and  2,  for  plastics.  Properties  not  listed  shall  be 
based  upon  material  tests.  (TBS) 

3. 3. 1.2  Finishes .  The  finishes  used  on  system  CIs  and  their  compo¬ 
nents  shall  be  resistant  to  corrosion.  There  shall  be  no  destructive 
corrosion  when  exposed  to  moderately  corrosive  environments  such  as  indus¬ 
trial  environments  or  sea  coast  fog.  Destructive  corrosion  shall  be  con¬ 
strued  as  being  any  type  of  corrosion  which  interferes  with  meeting  the 
specified  performance  of  the  device  or  its  parts. 

3. 3. 1.3  Material  Selection.  Materials  shall  be  selected  that  have 
demonstrated  their  suitability  for  the  intended  application.  Materials 
used  shall  be  resistant  to  fungus.  Use  shall  not  be  made  of  combustible 
materials  or  materials  that  can  generate  toxic  products  of  combustion. 
Protection  of  dissimilar  metal  combinations  shall  be  in  accordance  with 
KIL-STD-889. 

3.3.2  Electromagnetic  radiation.  The  system  shall  be  designed  in 
accordance  with  MIL-STD-1541.  Tempest  requirements  are  (TBS). 

3.3.3  Nameplates  and  product  marking.  The  system  CIs  and  each  inter¬ 
changeable  subassembly  shall  be  identified  by  a  nameplate.  The  nameplate 
identification  may  be  attached  to,  etched  in,  or  marked  directly  on  the 
item.  Metal  stamping  shall  not  be  used.  Nameplates  shall  contain,  as  a 
minimum,  the  following  identifications: 

a.  Item  or  Cl  number 

b.  Serial  number 

c.  Lot  or  contract  number 

d.  Manufacturer 

e.  Nomenclature 

When  size  limitations,  cost,  or  other  considerations  preclude  marking  all 
applicable  information  on  an  item,  the  nameplate  may  simply  provide  a 
reference  key  to  cards  or  documents  where  the  omitted  nameplate  information 
may  be  found. 
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3-3.4  VJorkmanship .  Equipment  shall  be  manufactured,  processed,  test¬ 
ed,  and  handled  such  that  the  finished  items  are  of  sufficient  quality  to 
ensure  reliable  operation,  safety,  and  service  life.  The  items  shall  be 
free  of  defects  that  would  interfere  with  operational  use,  such  as  exces¬ 
sive  scratches,  nicks,  burrs,  loose  materials,  contamination,  and  corro¬ 
sion. 

3.3.5  Interchangeability .  The  design  of  ground  equipment  shall 
provide  for  modular  replacement  of  components  to  expedite  maintenance  and 
repair.  The  design  of  space  elements  shall  provide  for  factory  replace¬ 
ment  of  components  and  for  pre-launch  installation  or  replacement  of 
explosive  ordnance  devices,  batteries,  and  major  space  vehicle  components. 

3.3.6  Safety.  The  system  shall  be  designed  to  minimize  safety  hazards 
to  personnel  and  surrounding  equipment  during  installation,  maintenance, 
ground  test,  transportation,  and  operational  use.  The  safety  requirements 
and  procedures  shall  comply  with  all  local,  state,  and  federal  requirements 
as  well  as  Range  Safety  manuals. 

3.3.7  Human  performance/human  engineering.  Newly  designed  equipment 
shall  be  in  conformance  with  MIL-H-46855  and  MIL-STD-i472 ,  observing 
principles  and  criteria  sec  forth  in  AFSC  Design  Handbook  1-3. 

3.3.8  Computer  programming.  Computer  programs  newly  developed  for  this 
program  shall  be  designed  and  structured  in  such  a  way  that  functional 
requirements  and  computer  program  components  may  be  modified,  added,  or 
deleted  without  requiring  extensive  restructuring  and  recoding  of  other 
components.  Programming  languages  shall  be  used  as  specified  in  3.7.x. 

...  (TBS) 


ELECTRONIC  SYSTEMS  -  COMMENT 

Although  the  system,  specification  is  primarily  a  performance -oriented  document, 
subsection  5.3  provides  a  place  for  specifj'ing  those  minimum  design/construc¬ 
tion  requirements  which  are  identified  as  being  essential  to  effective  Air 
Force  use  or  support  of  the  system.  Specification  writers  have  the  obligation 
to  assure  that  such  requirements  are:  necessary-,  in  fact;  consistent  with 
estimated  program  schedules  and  costs;  and  also  fully  compatible  with  basic 
performance  requirements  set  forth  in  other  parts  of  the  specification. 

It  happens  that  paragraph  3.3.8  is  the  onlv  part  ot  a  s\-steni  specification  for 
which  instructions  contained  in  either  MTL-STl'-490  or  'W.  STlt-483  make  explicit 
mention  of  computer  programs.  Possibly  due  to  that  f.-ut ,  there  has  been  a 
noticeable  tendency  to  overemphasize  its  importance  both  as  a  part  of  this 
subsection  and  in  relation  to  other  areas  of  system  requirements  (e.g.,  see 
preceding  comment  on  paragraph  3.2.1).  One  svstem  specification  was  issued  in 
1979- -admittedly ,  a  "wor.st  case''--in  which  3.3.8  alone  occupied  12%  of  the 
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page  svaoe  in  the  entire  speaifiaationl  However,  it  is  clear  that  needs  exist 
for  better  guidance  in  this  area  than  has  yet  been  icrmulated  for  general  use. 
Appendix  B  of  this  guidebook  contains  a  sample  of  one  approach  which  has  been 
proposed,  together  with  further  comments  on  associated  questions  and  problems. 


Subsection  3.4,  Documentation.  This  subsection  is  where  general  documentation 
requirements  should  be  specified.  It  should  be  noted  that  no  requirements  for 
the  delivery  of  documents  or  data  may  be  included  in  this  paragraph,  nor  else¬ 
where  in  the  specification.  Data  or  documents  to  be  delivered  for  review  or 
approval  must  be  listed  in  the  CDRL  and  referenced  in  the  contract.  Tlie 
requirements  included  in  this  paragraph  shtuld  outline  the  general  plan  for 
engineering  drawings,  specifications,  technical  manuals  and  other  types  of 
documentation  required  to  support  design  reviews,  manufacturing,  testing, 
operations,  maintenance,  and  logistic  support. 


3.4  Documentation.  Only  documentation  listed  in  the  Contract  Data 
Requirements  List  (CDRL)  shall  be  formally  delivered  for  review  or 
approval.  It  is  intended,  however,  that  during  the  course  of  the  system 
acquisition  process  appropriate  results  of  trade  studies,  analyses,  and 
development  efforts  will  be  internally  documented  to  support  design  deci¬ 
sions  and  scheduled  technical  reviews.  The  final  system  documentation 
shall  be  such  that  subsequent  production  items  can  be  produced  that  are 
equivalent  in  all  respects  to  those  tested  or  delivered.  This  final  docu¬ 
mentation  shall  also  be  adequate  to  allow  the  rapid  incorporation  of 
changes  when  necessary.  Operational  procedures  manuals  shall  include 
contingency  prucedures  to  minimize  the  impact  of  possible  anomalies. 


ELECTRONIC  SYSTEMS  -  COMMENT 

It  is  normally  advisable  to  include  in  this  paragraph  requirements  for  computer 
program,  documentation  which  will  tend  to  enforce  conformance  with  policies  set 
forth  in  APR  800-14.  Examples  of  .statements  to  be  considered  are: 

"All  computer  programs  developed  as  a  part  of  this  system  program  shall 
be  soecified  in  accordance  with  the  format  and  content  instructions  of 
MIL-STD-4S5  fU.SAF),  Appendix  Vf." 

"Computer  program  specifications,  manuals,  handbooks,  test,  and  version 
description  documents  shall  be  maintained  for  the  life  of  each  CPCI  to 
reflect  all  Class  I  and  Class  II  changes,  and  the  responsible  computer 
program  developer  or  support  activity  shall  issue  periodic  reports  to 
enable  verification  of  their  status,  in  accordance  with  Appendix  VIII  of 
MIL- STD- 483." 

Such  statements  function  as  requirements  to  be  observ^ed,  not  directly  bv  con¬ 
tractors,  but  b\-  Progr.'im  Office  personnel  responsible  for  the  iirenarat  ion  of 
contract  SOKs  and  CHRI.s. 
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Subsection  3.5,  Logistics.  This  subsection  states  the  logistic  requirements 
which  constrain  the  system  design.  The  allocation  of  the  program  level  logistic 
requirements  to  the  system  and  to  lower  tier  levels  is  generally  based  on  mini¬ 
mizing  the  program  and  system  life  cycle  costs.  Production  quantitites,  main¬ 
tenance,  and  refurbishment  opportunities  for  space  systems  are  extremely 
limited  when  compared  with  other  military  equipment.  This  factor  usually  dic¬ 
tates  that  the  contractor  be  assigned  responsibilities  for  logistic  support  for 
the  life  of  the  system.  Nevertheless,  there  may  be  requirements  that  should  be 
stated  here  to  assist  the  contractor  in  the  design. 

Paragraph  3.5.1,  Maintenance,  would  typically  address  such  items  as;  (a)  the 
extent  of  maintenance  to  be  accomplished  at  specified  locations  such  as  at  the 
launch  site,  on-orbit,  at  the  landing  site,  at  operating  sites,  at  the  depot  if 
one  is  to  be  used,  or  at  the  factory;  (b)  test,  maintenance,  repair,  and  refur¬ 
bishment  time  lines;  (c)  use  of  multipurpose  test  equipment;  and  (d)  the  use  of 
module  vs.  part  replacement. 

Paragraph  3.5.2,  Supply,  would  address  such  items  as:  (a)  supply  or  resupply 
methods;  (b)  special  storage  requirements  for  parts  or  items;  (c)  introduction 
of  new  parts  or  items  into  the  supply  system;  and  (d)  distribution  and  location 
of  item  stocks. 

Paragraph  3.5.3,  Facilities  and  facility  equipment,  would  address  the  impact,  if 
any,  on  existing  facilities  and  facility  equipment  or  any  requirements  for  new 
facilities  or  ancillary  equipment  to  support  the  system  logistics.  The  facility 
and  facilitv  equipment  requirements  would  eventually  be  transferred  to  separate 
facility  specifications  or  other  appropriate  documents  to  support  their  procure¬ 
ment.  Generally  facility  procurements  and  space  system  equipment  procurements 
are  entirely  separate  contracts. 


3.5  Logistics .  Equipment  designs  shall  be  based  upon  minimizing  the 
system  life  cycle  cost  assuming  the  contractors  provide  the  logistic  sup¬ 
port  for  the  system  for  its  service  life. 

3.5.1  Maintenance.  (TBS) 

3.5.2  Supply .  (TBS) 

3.5.3  Facilities  and  facility  equipment.  (TBS) 


ELECTRONIC  SYSTEMS  -  COMMENT 

The  .standard  breakdown  of  thi.s  subsection  into  parapraphs  for  maintenance, 
sunply,  facilities  and  facility  equipment  does  not  clearly  provide  for  computer 
program  support,  but  that  topic  should  be  covered.  A  recommended  approach  is 
to;  (a)  use  the  three  standard  paragraphs,  as  intended,  for  equipment  and 
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facilities  only;  (b)  add  a  fourth  parapraoh  entitled  "Computer  Program  Support"; 
and  (c]  insert  a  sentence  into  the  basic  paragraph  5.5  calling  attention  to  this 
organization.  Requirements  addressed  in  the  additional  paragraph  f3.5.<3!  should 
include  identification  of  the  responsible  support  center  (e.g.,  N'CPC,  Sacra¬ 
mento  ALC,  or  other,  following  the  initial  period  of  contractor  support],  and 
identification  of  support  functions  to  be  provided  at  the  operating  site^s]. 

In  formulating  requirements  in  the  context  of  this  topic  (logistics],  specifica¬ 
tion  writers  should  be  aware  that  "maintenance"  is  basically  a  misnomer  for  a 
computer  program  support  activitv,  which  t>'pically  devotes  the  bulk  of  its 
allocated  time  and  effort  to  making  modifications.  Nfost  of  those  modifications 
may  be  minor  and  relatively  routine;  however,  every  "fix"  to  a  CPCI  is  a  design 
change,  which  implies  that  planning  in  this  area  must  be  closely  linked  witli 
planning  for  system/software  configuration  management  (see  .APR  800-14,  Chapter 
6,  Section  C] . 


Subsection  3.6,  Personnel  and  training.  This  subparagraph  generally  starts  with 
a  title  heading  for  the  paragraphs  that  follow.  For  space  systems,  most 
personnel  and  training  requirements  are  usually  determined  by  the  contractors. 

If  it  is  Intended  that  military  personnel  will  operate  or  maintain  the  system 
equipment,  it  is  important  that  the  required  number  of  personnel  at  each  of  the 
available  skill  levels  be  identified.  For  contractor  operation  or  maintenance 
it  would  be  appropriate  to  describe  in  general  terms  the  educational  background, 
experience,  or  other  qualifications  desirable  for  personnel  selected  to  be 
trained  to  operate  and  maintain  the  system.  Care  should  be  taken  to  avoid 
overly  restrictive  personnel  requirements  because  they  can  impose  costly  con¬ 
straints  on  the  equipment  design  and  on  other  areas  of  the  program  such  as 
requirements  for  spares.  The  training  paragraph  could  address  such  requirements 
as: 

a.  The  concept  of  how  training  should  be  accomplished,  e.g.,  school,  unit, 
or  contractor  training. 

b.  The  need  for  simulators,  training  aids,  or  other  training  equipment 
or  devices. 

c.  The  expected  training  time  and  locations  available  for  training 
programs. 

Subsection  3.7,  Functional  area  characteristics.  This  subsection  generally 
starts  with  a  title  heading  for  the  paragraphs  that  follow.  A  paragraph  would 
be  established  to  address  each  of  the  system  segments  of  the  system  that  were 
identified  in  3.1  of  the  specification.  The  requirements  in  these  paragraphs 
may  be  stated  by  simply  referencing  the  applicable  system  segment  specifications 
if  they  exist.  For  the  space  system,  the  system  segment  requirements  may  be 
so  extensive  that  it  may  be  desirable  to  simply  prepare  the  space  system  segment 
specification  at  the  same  time  the  space  system  specification  is  prepared.  In 
that  case,  the  space  system  segment  specifications  will  detail  the  system  per¬ 
formance  characteristics,  physical  characteristics,  special  requirements,  and 
interface  characteristics  allocated  to  each  functional  area/system  segment, 
following  the  full  range  of  format /content  conventions  which  apply  to  the  system 
specification  itself. 
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3 . 6  Personnel  and  training . 

3.6.1  Personnel.  (TBS) 

3.6.2  Training .  (TBS) 

3.7  Functional  area  characteristics. 

3.7.1  Space  cvstem  segment.  (TBS) 

3.7.2  Ground  terminal  system  segment.  (TBS) 

3.7.3  Data  reduction  system  segment.  (TBS) 


Subsection  3.8,  Precedence.  Paragraphs  in  the  Model  Specification  are  typical 
boilerplate  for  a  system  specification.  They  address  (a)  precedence  as  it 
refers  to  potential  conflicts  with  other,  referenced  documents,  and  (b)  orders 
of  priority  for  requirements  stated  in  the  system  specification: 

Paragraph  3.8.1,  Conflicts,  states  considerations  in  resolving  conflicts  that 
may  occur  with  referenced  documents.  The  general  rule  is  that  requirements 
stated  in  a  given  document  take  precedence  over  conflicting  requirements  of 
referenced  documents.  In  the  case  of  other  system  specifications,  or  documents 
prepared  by  other  agencies,  it  is  especially  important  that  conflicts  be  iden¬ 
tified  and  resolved.  The  purpose  of  boilerplate  words  in  the  Model  Specifica¬ 
tion  is  to  assure  that  conflicts  with  those  other  documents  be  made  known  and 
directed  to  the  Contracting  Officer  for  resolution. 

Paragraph  3.8.2,  Requirements  weighting  factors,  states  the  relative  importance 
of  requirements  stated  within  the  specification,  since  those  may  not  be  equal. 
Relative  weights  might  be  assigned  to  requirements  in  different  areas,  such 
as  interfaces,  performance,  or  physical  characteristics.  The  relative  weight¬ 
ing  of  individual  factors  by  the  manner  in  which  they  are  stated,  although 
common  practice,  should  be  stated  here  if  it  is  used.  The  suggested  four 
levels  may  be  expanded,  reduced,  or  not  used  at  all  in  a  given  specification. 
Note  that  these  factors  are  appropriate  only  during  early  phases  of  a  program; 
they  should  not  appear  in  product  specifications  intended  to  support  a  produc¬ 
tion  contract. 


3 . 8  Precedence. 

3.8.1  Conflicts.  In  the  event  of  conflict  between  the  documents  ref¬ 
erenced  herein  and  the  contents  of  this  specification,  the  contents  of  this 
specification  shall  be  considered  the  superseding  requirements,  except  when 
a  conflict  involves  interface  requirements  external  to  this  system.  In  the 
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event  of  conflicts  involving  external  interfaces,  the  order  of  precedence 
shall  be  as  directed  by  the  Contracting  Officer. 


3.8.2  Requirements  weighting  factors.  Compliance  with  requirements 
stated  within  this  specification  shall  be  governed  by  the  following  factors: 

a.  "Shall"  designates  the  most  important  weighting  level.  Compliance 
with  these  requirements  is  mandatory. 

b.  "Shall,  where  practicable"  permits  alternative  designs,  items  or 
practice  to  be  used  when  the  use  of  the  alternative  is  substanti¬ 
ated  by  documented  technical  trade  studies.  These  trade  studies 
shall  be  made  available  for  review  or  provided  to  the  Government 
in  accordance  with  the  contract  provisions.  Deviations  from  these 
requirements  do  not  require  formal  approval  by  the  Contracting 
Officer . 

c.  "Preferred"  or  "should"  designates  requirements  from  which  devia¬ 
tions  do  not  require  either  documented  technical  substantiation 
nor  Contracting  Officer  approval. 

d.  "May"  requirements  are  stated  as  examples  of  acceptable  designs, 
items,  and  practices.  Unless  required  by  other  contract  provi¬ 
sions,  deviations  from  these  requirements  do  not  require  technical 
substantiation  nor  Contracting  Officer  approval. 


APPENDIX  B.  SA^PLE  PARAGRAPH  5.5.8 


Paragraph  5.5.8  is  a  part  of  the  system  specification  which  is  not  men¬ 
tioned  in  MIL-STD-490  but  is  called  out  for  Air  Force  use  in  MIL-STD-485 
Appendix  III  (para.  30. 51.  Its  function  is  to  provide  a  place  in  the  svsten 
specification  to  specify  requirements  for  comouter  programs  that  are  comparable 
to  the  types  of  design  and  constmction  standards  specified  in  other  part.=  of 
paragraph  3.5  as  a  whole  for  items  of  system  equipment.  It  happens  to  be  a 
part  of  the  system  specification  which  has  received  widespread  attention  and 
emphasis  in  the  past  few  years;  and  the  resulting  technical  requirements  con¬ 
tained  in  various  system  specifications  have  tended  to  meet  with  almost -equal Iv 
widespread  controversy. 

One  sample  of  specification  requirements  for  this  paragraph  which  has  been 
proposed  for  general  use  is  reproduced  below.  It  is  presented  here  as  an  illus¬ 
tration,  not  as  a  recommendation.  The  sample  is  followed,  in  this  appendix,  by 
a  few  additional  comments  pertaining  to  its  merits  and  shortcomings  from  the 
point  of  view  of  acquisition  management  practices. 


This  general  sample  contains  minimum 
essential  requirements  and  is  intended 
to  serve  as  guidance  for  composing  a 
System  "A"  Specification  Section  3.3.8. 

3.3.8  Computer  Programming.  Computer  programs  and  computer  data  bases 
shall  be  considered  as  software.  Software  shall  be  categorized  as  support 
software  or  applications. 

3. 3. 8.1  General  Requirements.  Software  shall  meet  the  following  design, 
language,  and  coding  requirements; 

3. 3. 8. 1.1  Design  Requirements 

3. 3. 8. 1.1.1  Comouter  Program  Structure.  The  computer  program  structure 
shall  consist  of  Computer  Program  Configuration  Itero(s),  Computer  Program 
Component (s) ,  and  Module (s). 

a.  Computer  Program  Configuration  Item  (CPCI).  A  CPCI  is  the  actual 
computer  program  end  item  in  the  form  of  computer  instructions  stored  on 
machine-readable  media.  A  CPCI  shall  consist  of  one  or  more  computer  pro¬ 
gram  components. 
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b.  Computer  Program  Component  (CPC).  A  CPC  is  a  functionally,  logi¬ 
cally  distinct  part  of  a  CPCI.  A  CPC  is  identified  for  purposes  of  conve¬ 
nience  in  specifying  and  developing  a  CPCI  as  an  assembly  of  subordinate 
elements.  A  CPC  consists  of  a  logical  composition  of  one  or  more  subordi¬ 
nate  or  interfacing  modules. 

c.  Module.  A  module  performs  a  complete  logical  process  by  execution 
of  a  set  of  instructions  which  have  clearly  defined  inputs,  processing 
logic,  and  outputs.  A  module  is  the  smallest  set  of  executable  statements 
able  to  be  assembled  or  compiled.  Each  module  shall  conform  to  the  follow¬ 
ing  conventions: 

(1)  A  module  shall  consist  of  a  set  of  instructions  in  a  form 
consistent  with  the  appropriate  language,  OS,  and  computer. 

(2)  A  module  shall  not  exceed  100  lines  of  executable  source 
code.  This  limitation  excludes  comments  and  data  definitions. 

(3)  A  module  shall  have  only  one  entr^-  statement  and  one  exit 

statement . 

3. 3. 8. 1.1. 2  Top  Down  Design  (TDD).  Software  developed  under  this  contract 
shall  be  designed  in  a  top  down  manner.  The  processing  activities  of  the 
system  shall  be  identified  and  organized  beginning  with  higher  levels  of 
organization,  expanded  and  broken  out  to  include  a  more  detailed  definition 
of  the  processing  activities  by  identification  of  subordinate  levels.  The 
lowest  level  of  processing  shall  correspond  to  the  module. 

3. 3. 8. 1.1.3  Top  Down  Implementation  (TDI) 

The  project  software  shall  be  implemented  in  a  top  down  manner 
as  defined  herein.  Conceptually,  top  down  implementation  proceeds  from  a 
single  starting  point  while  conventional  implementation  proceeds  from  as 
manv  starting  points  as  programs  in  the  design.  The  single  starting  point 
does  not  imply  that  the  implementation  must  proceed  down  the  hierarchy  in 
oarallel.  Some  branches  intentionally  will  be  developed  earlier  than  other 
branches.  For  example,  user  or  other  external  interfaces  might  be  imple¬ 
mented  before  some  of  the  other  partitions  to  permit  early  demonstration  of 
software  subsystem  capabilities,  partial  software  system  evaluation,  train¬ 
ing,  or  even  incremental  software  system  acceptance.  The  project  software 
shall  be  implemented  in  a  series  of  RELEASES  which  shall  provide  for 
successive  system  capabilities. 

3. 3. 8. 1.2  Programming  Languages.  Software  developed  for  this  svstem  shall 
ne  restricted  to  one  or  more  of  the  following  languages: 

a.  FORTRAN  as  per  ANSI  STD  X  3.10  -  1966 
I  b.  FORTRAN  as  per  ANSI  STD  X  3.9  -  1978 
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c.  JOVIAL  J3  as  per  MIL  STD  1588 


d.  JOVIAL  J73  as  per  MIL  STD  1589A 

e.  COBOL  as  per  FIPS  PUB  21-1 

f.  IEEE  ATLAS  Spec.  416A-1978 
3. 3. 8. 1.3  Coding  Requirements. 

3. 3. 8. 1.3.1  Commenting  Standards.  Software  developed  under  this  contract 
shall  adhere  to  the  following  commenting  standards: 

3. 3. 8. 1.3. 1.1  Banners.  A  banner  shall  be  a  block  of  comments  which  appears 
once  at  the  beginning  of  each  module.  A  banner  shall  visually  break  the 
project  software  into  units  of  codes  corresponding  to  the  CPCI  decomposit ior. 
(module  level) .  Banners  shall  have  an  identical  format  for  each  module 
within  a  CPC.  The  banner  shall  enclose  the  following  information:  CPCI 
title,  CPIN,  CPC  title,  and  CPC  number.  The  banner  shall  occur  once  in  each 
module  listing,  immediately  preceding  the  header. 

3. 3. 8. 1.3. 1.2  Headers.  Headers  shall  consist  of  a  block  of  consecutive 
comments  arranged  to  facilitate  the  understanding  and  readability  of  each 
module.  This  form  of  block  commenting  shall  be  used  in  lieu  of  individual 
comments  being  scattered  throughout  a  module.  Headers  shall  occur  once  at 
the  beginning  of  each  module  and  shall  conform  to  the  standards  described 
herein.  The  observer  shall  be  able  to  read  the  MODULE-HEADER  and  understand 
the  processing  activities  of  the  module  without  having  to  read  program  code. 
The  minimiT' required  MODULE-HEADER  comments  are  described  below.  These 
comments  shall  appear  in  the  form  and  in  the  order  illustrated  below; 

MODULE-HEADER  COMMENTS 

MODULE-NAME  -  Followed  by  a  one-line  functional  description. 

ABSTRACT  -  The  ABSTRACT  shall  be  a  set  of  consecutive  comments  which 
describe  the  module's  purpose,  use,  and  processing  activities.  Elaboration 
on  the  technical  aspects  of  the  algorithms  should  be  avoided  where  refer¬ 
ences  to  external  Government  documentation  would  suffice.  The  ABSTRACT 
should  paraphrase  the  activities  of  the  code  in  English  terms.  References 
made  to  external  Government  owned  documentation  shall  be  listed  in  the 
REFERENCES  comment  section. 

REFERENCES  -  NO-1,  TITLE,  DATE  (YY/MM/DD) 

NO-2,  etc. 

INPUTS  -  Variables,  Tables  (local,  system),  files,  and  other  data 
input  sources  shall  be  identified  senarately  as  tc  type,  unit  of  measure, 
size,  limits  and  ranges  of  unit  of  measure,  accuracy  or  precisi('n 
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requirements,  frequency  of  arrival. 

OUTPUTS  -  Variables,  Tables  (local,  system).  Files  and  other  data  out¬ 
put  sources  shall  be  identified  in  the  same  manner  as  inputs. 

PROGRAMS  CALLED  -  Names  of  other  programs  called  followed  by  brief 
abstract  of  purpose  and  pre  and  post  conditions  of  each  call, 

LIMITATIONS  -  Description  of  any  constraints  upon  the  execution  of  the 
program.  For  instance,  conditions  which  would  alter  the  logical  operation 
of  the  program  or  cause  the  results  of  the  program’s  computations  to  be 
altered . 

MODIFICATIONS  -  NO-1,  MOD  description,  DATE  (YY/MM/DD) 

NO-2,  etc. 

3. 3. 8. 1.3. 1.3  Special  Comments.  Wherever  code  is  particularly  subtle  or 
confusing,  SPECIAL-COMMENTS  shall  precede  the  statement (s)  to  describe  the 
activities  of  the  subject  code.  SPECIAL-COMMENTS  are  provided  only  to  aid 
the  observer  in  reading  program  code  and  are  not  intended  to  replace 
MODULE-HEADER  comments. 

3. 3. 8. 1.3. 2  Structured  Coding.  Computer  programs  coded  for  the  system 
shall  employ  only  the  control  constructs  listed  below.  These  constructs 
shall  be  built  using  logically  equivalent  language  simulations.  Instruc¬ 
tions  in  the  language  used  shall  follow  the  graphic  representations  in 
Figure  1. 

a.  SEQUENCE.  Sequence  of  two  or  more  operations. 

b.  IF-THEN-ELSE .  Conditional  branch  to  one  of  two  mutually  exclusive 
operations  and  continue. 

c.  DO-WHILE.  Operation  repeated  while  a  condition  is  true.  Test  is 
before  operation. 

d.  CASE.  Select  one  of  many  possible  cases. 

3. 3.8.2  Operating  System  (OS)  Requirements.  The  OS  shall  conform  to  the 
following  requirements; 

a.  The  OS  shall  be  a  vendor-supplied,  off-the-shelf  package. 

b.  OS  augmentations  shall  be  allowed  but  shall  be  limited  to  the 
design  of  new  software.  No  augmentations  shall  be  permitted  to  be  embedded 
within  the  vendor  supplied  OS  software. 

r.  For  all  augmentations,  contractor  developed  software  shall  be 
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developed  to  interface  the  vendor-supplied  OS  for  all  OS  augmentations. 

d.  No  OS  interface  or  augmentation  software  shall  compromise  the 
capability  of  the  OS  vendor  to  provide  maintenance  over  the  life  cycle  of 
the  systems. 

e.  No  instructions  shall  be  executed  that  will  cause  the  computer  to 
halt  processing  pending  an  external  event,  except  by  the  OS.  An  exception 
to  this  restriction  shall  be  permitted  for  augmentations  to  the  O.S  where 
the  augmentation  is  designed  as  an  extension  of  the  processing  control  of 
the  OS.  The  exception  is  subject  to  review  and  approval  by  the  Government 

3. 3. 8. 3  Firmware  Requirements.  Computer  programs  and  data  loaded  in  a 
class  of  memory  that  cannot  be  dynamically  modified  by  the  computer  during 
processing  shall  be  considered  firmware.  Requirements  on  firmware  shall  be 
the  same  as  those  on  software.  Use  of  firmware  shall  be  subject  to 
approve]  by  the  Government. 

3. 3. 8. 4  Software  Utility  Services.  This  support  software  shall  provide 
the  following  minimum  capabilities: 


a. 

b. 

c . 

d. 

programs 

e . 


Compilation. 

Assembly  which  produces  relocatable  object  code. 

Linking  type  loader. 

Generation,  maintenance,  and  initialization  of  storage  media  for 
and  data. 

Diagnostics  to  support  fault  isolation. 


f.  Editing  and  debugging  tools. 

3. 3.8.5  Message  Generation.  The  generation  of  error/diagnostic  messages 
shall  make  a  distinction  between  (1)  the  requirements  for  on-line  messages 
to  facilitate  real-time  fault  Isolation  required  to  maintain  the  system  in 
operational  status  and  (2)  the  logging  of  fault  messages  onto  svstem  files 
for  the  category  of  faults  which  require  Isolation  and  correction  but  can 
be  addressed  off-line  and  do  not  degrade  the  system  performance.  The 
required  processing  time  to  iden  .fy  and  generate  an  error/diagnostic 
message  either  for  on-line  or  off-line  isolation  and  correction  shall  not 
degrade  the  operational  requirements  of  the  system. 


a.  Processor  message  and  advisorv  formats  shall  not  require  addi¬ 
tional  interpretation  by  the  operator,  such  as  table  lookups  and  references 
to  documentation,  with  the  exception  of  lengthv  diagnorric  procedures  to  be 
followed  by  the  operator  following  an  abnormal  condition. 
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b.  No  computer  program  shall  generate  a  message  or  advisory  identical 
to  one  generated  by  the  OS  or  by  another  program. 

c.  Off-line  error  messages  shall  contain  as  a  minimum  the  following 
information: 

(1)  Time  error  was  detected. 

(2)  Textual  description  of  error  condition. 

(3)  Required  operator  action  where  applicable. 

(4)  Contents  of  instruction  register  and  program  counter  at  time 

of  error. 

(5)  Identification  of  triggering  module. 

(6)  Computer  program  or  sy.stem  execution  status  following  the 

error . 

On-line  error  messages  shall  contain  as  a  minimum  the  information  in  items 
(1),  (2),  and  (3)  above. 

3. 3.8.6  Program  Coding  Conventions.  Software  developed  under  this  contract 
shall  conform  to  required  coding  conventions  stated  below, 

a.  Each  line  of  source  code  shall  contain  no  more  than  one  statement. 

b.  Source  code  shall  be  clearly  and  conspicuously  annotated  to  explain 
all  inputs,  outputs,  branches,  and  other  items  not  implicit  in  the  code 
itself . 

c.  Names  of  operator  commands,  data  entries,  program  components, 
variables,  procedures,  and  other  software  components  shall  be  consistent 
with  those  used  in  system  design. 

d.  Code  shall  be  written  such  that  no  code  is  modified  during 
execution. 

3. 3. 8. 7  Character  Set  Standards.  Character  sets  shall  conform  to  standards 
in  FIPS-1  Standard  Code  for  Information  Interchange,  ANSI-X3. 4-1968. 


Note:  Figure  1,  Control  Constructs 
is  maintained  at  ESD/TOIS 
AV/478-2701 
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The  followinc;  conmonts  represent  opinions  of  this  author,  based  on  con¬ 
siderations  pertaining  to  the  suitability  of  the  proposed  sam}ile  for  its  intended 
function  as  a  part  of  the  system  specification.  Technical  merits  of  the 
material,  as  such,  are  not  addressed  here,  although  it  should  perhaps  be  noted 
that  various  portions  of  the  content  have  met  with  both  some  agreement  and 
some  disagreement  among  technical  reviewers. 

Overall,  only  some  portions  of  the  requirements  set  forth  in  this  sample 
are  truly  appropriate  to  intended  and  actual  functions  of  paragraph  3.3.8  in 
the  system  specification.  Roughly  half  of  the  material  does  illustrate  a  form 
and  type  of  material  which  is  in  accordance  with  accepted  specification  prac¬ 
tices,  while  the  other  half  appears  to  have  been  formulated  for  other  purposes. 
Further  work  is  needed  to  "separate  the  wheat  from  the  chaff",  and  to  better 
reflect  the  system  acquisition/contracting  implications  of  requirements  stated 
in  a  system  specification,  llore  specifically: 

a.  Portions  of  the  material  which  do  constitute  requirements  suitable  for  this 
paragraph  are  those  specifying  characteristics  of  the  conputer  program 
design  and  coding -• i. e. ,  as  contained  in  subparagraphs:  3. 3. 8. 1.1. 2,  Top 
Down  Design;  3. 3. 8. 1.2,  Programming  Languages;  and  3. 3. 8. 1.3. 2,  Structured 
Coding.  When  specified  in  3.3.8,  it  must  be  assumed  that  the  requirements 
are  intended  to  apply  to  all  developmental  CPCIs  in  all  system  segments: 
otherwise,  they  should  be  specified  in  paragraph  5.7  or  in  the  T>T)e  B5 
(Part  I)  specifications  for  individual  CPCIs. 

b.  The  sample  as  a  whole  is  at  odds  with  the  significant  principles  that 
design  and  construction  requirements  should  (1)  be  held  to  a  minimum  and 
(2)  make  maximum  use  of  references  to  existing  standards.  Its  extensive 
coverage  and  detail  suggest  that  this  sample  is  written  more  as  a  vehicle 
for  disseminating  a  variety  of  proposed  general  computer  programming 
standards  than  as  a  serious  model  of  content  for  the  system  specification 
as  such.  That  imnression  stems  somewhat  from  repeated  appearance  of  the 
phrase,  "...under  this  contract"  (3.3.8. 1.1. 2,  3. 3. 8. 1.3.1,  5.3.8.61-- 

a  phrase  which  should  be  reserv’ed  for  some  other  tiqie  of  document --as  well 
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as  from  the  questionable  emphasis  devoted  to  requirements  in  such  areas  as 
the  following: 

(1)  Paragraph  5.3.8.1.1.3,  Top  Down  Implementat ion  (TDI ] .  These  are 
requirements  for  contractor  internal  procedures,  not  for  CPCI  design 
and  construction.  As  such,  they  represent  a  level  of  requirements 
which  should  normally  be  avoided  altogether,  in  either  specifications 
or  contract  statements  of  work.  Such  procedures  are  best  left  for 
the  contractor  to  propose  voluntarily,  e.g.,  as  a  part  of  his  computer 
program  development  and/or  quality  assurance  plans. 

(2)  Paragraphs  3. 5. 8. 1.3  through  3. 3. 8. 1.5. 1.3.  These  are  requirements, 
not  for  design  and  construction  as  such,  but  for  contractor-deliverable 
information  about  the  design  and  construction.  Such  requirements  have 
no  function  in  the  system  specification.  They  will  yield  the  desired 
results  only  if  expressed  specifically  in  each  contract,  in  the  CDRL, 
and  properly  coordinated  with  backup  instructions  provided  therein 

for  (a)  delivery  and  content  of  the  O^CI  product  specification  (DI-E- 
3120A)  and  fb)  delivery  of  the  CPCI  itself  (DI-E-3014S) . 

r3)  Paragraphs  3. 3. 8. 4  and  3. 3. 8. 5.  These  are  requirements,  again  not  for 
design  and  construction,  but  for  system  functional  capabilities,  w'hich 
should  be  determined  for  each  system  and  spelled  out  elsewhere  in  the 
body  of  the  system  specification- -notably,  in  paragraph  3.2  and  appro¬ 
priate  subparagraphs  under  3.7. 

(4)  Paragraph  3. 3.8.6,  Program  Coding  Conventions.  This  paragraph  seems 
to  consist  of  a  mixture  of  "afterthoughts": 

•  Subparagraph  fb)  is  subject  to  the  comment  [2)  abow. 

•  Subparagraph  (cl  is  a  tautolog>'. 

•  Subparagraph  (dl :  The  phrase,  "...such  that  no  code  is  modified 
during  execution"  appears  to  be  loosely  wordedT  as  written,  it 
covers  coded  data  values  as  well  as  computet  instructions. 
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.APPENDIX  C.  SA>.1PLE  FUNCTIONAL  FLOIV  BLOCK  DIAGRANJS 


This  appendix  prov'ides  a  few  examples  of  functional  flow  block  diagrams 
(FFBDs) ,  illustrating  one  prominent  form  of  system  engineering  documentation 
which  should  normally  be  contained,  or  referenced,  in  paragraph  5.1.4  of  a 
system  specification. 

The  follow'ing  figures,  C'l  through  C-6,  are  drawn  from  a  system  segment 
specification  prepared  for  the  Data  Systems  Modernization  fDSM)  Program, 
reference  16.  The  complete  set  of  FFBDs  contained  in  that  source  consisted  of 
116  diagrams  covering  top-level  through  fourth-  (and  in  some  cases,  fifth-) 
levels,  for  twelve  major  functions.  The  samples  reproduced  here  are  selected 
to  illustrate:  (aj  the  one,  top-level  FFBD  for  the  segment;  and  fbj  one  each 
of  the  first-  through  fourth-level  diagrams. 

Figure  C-1  illustrates  specific  logic  notations  used  in  constructing  these 
FFBDs.  General  rules  and  format  for  the  diagrams  are  based  on  instructions 
contained  in  DI- 5-3604, 

NOTES: 

a.  Functions  shown  in  parallel  may  interact,  although  interconnecting  lines 
are  not  provided  to  denote  those  interactions. 

b.  These  diagrams  show  only  the  flow  of  functions/subfunctions  required  to 
carr>'  out  the  system  mission.  Associated  narrative  definitions,  data 
content,  and  performance  requirements  derived  in  the  course  of  generating 
the  FFBDs  are  documented  in  other  sections  and  paragraphs  of  the  system 
specification. 

c.  The  diagrams  reproduced  here  are  selected  to  illustrate  one  vertical 
"thread"  within  the  total  FFBD  hierarchy- - i. e. ,  each  lower- level  diagram 
expands  one  function  shown  in  the  preceding  diagram.  Arrow's  are  added,  in 
these  figures,  to  identify  the  successively- expanded  functions. 
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Figure  C-1.  Logic  Notations. 


Figure  C-2.  Top-Level  Functional  Flow  Flock  Diagram. 
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SUPPORT  INTEGRATED  OPERATIONS  PLANNING  AND  PREPARATION 


PERFORM  MISSION  PLANNING  SUPPORT 
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RECEIVE/FORMAT  COMMAND  PROCESSING  PARAMETERS 


APPENTDIX  D.  REFERENCES 


(n  .4FR  57-1,  Statement  of  Operational  Need  fSON’s  11!  June  IS-P. 

fZj  .XFR  80C-14,  Volume  II,  Acquisition  ar.d  Support  Procedures  for  Computer 
Resources  in  Systems.  26  September  1975. 

''5':  AFSCP  800-3,  A  Guide  for  Program  Management.  9  April  19'’6. 

fa'  .AFSCP  80C-6,  Statement  of  Work  Preparation  Guide.  18  Vurust  lO'Z. 

{"SI  ,‘AFSCP  800- ",  Configuration  Management.  1  December  1977. 

fb'i  MIL- STD- 483  (US.AF) ,  Configuration  Management  Practices  for  Systems, 

Equipment,  and  Computer  Programs.  12  April  19"1.  Notice  2.  21  March  19" 9. 

MiL-STP-490,  Specification  Practices.  30  October  1968. 

rSi  MIL-STD-1321A  fUSAFl ,  Technical  Reviews  and  .Audits  for  Systems,  Equip¬ 
ment,  and  Computer  Prograats'.  1  .June  1975. 

f91  MIL-S-83490,  Specifications,  Types  and  Forms.  30  October  1968. 

fb'*'  DI-S-3604.  Functional  Flow  Block  Diagrams.  1  November  1971. 

{llj  DI-S-3605,  Requirements  Allocation  .Sheets.  November  1971. 

(12;>  DI-S-3606,  System/Desi,gn  Trade  Study  Reports.  1  November  1971. 

fl.'''  DI-S-3n07,  Schematic  Block  Diagrams.  1  .November  19"1. 

Mi)  DI-E-3120A,  Computer  Program  Product  Specification.  17  April  19"2. 

flSl  DI-E-30145,  Computer  Software  ./Computer  Program/Computer  Data  Base 
Configuration  Item'^s).  9  Ma}'  1  97^ 

'ItD  SS-SCF-0C016O,  ReouiTements  and  Design  Criteria  for  Command  and  Control 
Segment  for  the  .Air  Force  Satellite  Control  facility.  31  Januarv’  1980. 

n")  DoD  Weapons  System  Software  Management  Study.  Johns  Hopkins  University, 
.Apnlied  Physics  Laborator>'.  APL'/.3klU  SR"5-."",  June  19"5. 

flS^  Searle,  L.  IE,  An  Air  Force  Guide  to  the  Computer  ProCTam  Developiment 

■Specification.  F.SD-TR-"8-i.s9.  Electronic  Systems  Division,  AFSC, 

Hanscom  AFB,  Massachusetts.  March  1976.  (.VTIS  Accession  No. 

.Ar-AC555^3; . 


If..- 


I 


nscisilio  PaGB  BLiAMC-NOr  IllJffiD 


.^PPE.VDIX  E.  ABBRB'IATIO.MS 


AFCC 

.AFDAP 

.AFLC 

.AFSC 

.APR 

ALC 

ATC 

CCE 

CDR 

CDRL 

Cl 

CPCI 

CPDP 

CRISP 

DSF 

DoD 

DSM 

DT5E 

ECP 

ESD 

FFBD 

HQ  USAF 

ICD 

^ENS 

N’CPC 

PCA 

PND 

PNP 

PO 

QQPRI 

RAS 

RFP 

SAM 

SCN’ 

SD 

SDR 

SENE 

SON 

SOK 

SRR 

TBD 

TBS 

TTE 

U'BS 


Air  Force  Communications  Command 

Air  Force  Desiijnated  Acquisition  Program 

Air  Force  Logistics  Command 

Air  Force  Systems  Command 

Air  Force  Regulation 

-Air  Logistics  Center 

Air  Training  Command 

Configuration  Control  Board 

Critical  Design  Review 

Contract  Data  Requirements  List 

Configuration  Item 

Computer  Program  Configuration  Item 

Computer  Program  Development  Plan 

Computer  Resources  Integrated  Support  Plan 

Determination  and  Findings 
Department  of  Defense 
Data  Systems  Modernization 
Development  Test  and  Evaluation 

Engineering  Change  Proposal 
Electronic  Systems  Division 

Functional  Flow  Block  Diagram 

Headquarters  United  States  Air  Force 

Interface  Control  Document 

Mission  Element  Need  Statement 

N'ORAD  Computer  Programming  Center 

Physical  Configuration  Audit 
Program  Management  Directive 
Program  Management  Plan 
Program  Office 

Qualitative  and  Quantitative  Personnel  Requirements 

Information 

Requirements  Allocation  Sheet 
Request  For  Proposal 

Software  Acquisition  Management 
Specification  Change  Notice 
Space  Division 
System  Design  Review 
System  Engineering  Management  Plan 
Statement  of  Operational  Need 
Statement  of  Work 
System  Requirements  Review 

To  Be  Determined 
To  Be  Supplied 

Test  and  Evaluation  'tester  Plan 
Work  Breakdown  Structure 
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